JavaScript计数，你靠得住吗？

parseInt 函数会忽略空格，并将初始的数字序列解析为整数。在这里，它在小数点处停止，因此只返回 123456。

一般来说，parseInt 在遇到非数字字符时会停止解析。这里，它在逗号处停止，因此只返回 123。

由于浮点数精度误差，0.1 + 0.2 并不完全等于 0.3。由于浮点数在内存中的存储方式，结果是 0.30000000000000004。处理浮点运算的 IEEE 754 标准是罪魁祸首，它无法精确表示某些数字。这是所有编程语言中的常见问题。最终你会遇到无限循环小数，无论哪种语言——计算机都只能停止追逐无限重复的数字。

一些语言如 Python 和 Java 提供了 Decimal 或 BigDecimal 来处理这个问题，但 JavaScript 没有内置这样的功能。你可以使用像 big.js 或 decimal.js 这样的库来处理这些情况。

（注意：有些语言被设计为在更高的逻辑层面上处理分数、虚数等，保留字面表达式。但它们仍然需要在硬件层面处理相同的浮点精度问题。）

由于 Number.MAX_VALUE 是 JavaScript 中最大的可表示常规数字，超过其限制会迅速溢出——基本上你会看到无意义的结果。将其乘以 2 会得到 Infinity。

你知道的，JavaScript 有时候就是这样。

.toFixed(2) 返回 5 的字符串表示，保留两位小数，因此结果是 "5.00"。

双点（5..toFixed(2)）是一种“技巧”，用于访问数字字面量的对象模型。

在 JavaScript 中，parseInt 和 parseFloat 都会将字符串 "42" 解释为数字 42。因此，parseInt("42") === parseFloat("42") 的比较结果为 true。parseInt 在遇到第一个非数字字符时停止解析，而 parseFloat 会继续解析直到遇到不属于浮点数的字符。但由于 "42" 中没有小数点或其他非数字字符，两个函数返回了相同的值。

BigInt 是与 number 不同的类型，因此 parseInt("42")（一个常规数字）与 BigInt("42") 并不严格相等。要进行比较，必须将两者转换为相同类型：BigInt(parseInt("42")) === BigInt("42")。

任何以 0x 开头的输入字符串都会自动被视为十六进制（基数 16）。 因此，这相当于传递基数 16。所以，parseInt("0x2A") 等同于 parseInt("2a", 16)。（不区分大小写。）

parseInt 使用十六进制（16）基数将 \"FF\" 转换为十进制 255。你可能在 CSS RGB/十六进制颜色代码中见过这个。

parseInt 的第二个参数（基数）与数组方法的 index 参数对齐。这会导致意外的结果，因为 parseInt("One", 1) 由于输入无效而返回 NaN。

第一个元素 24 在基数为 0（自动检测）时被解析为 24，因此保持为 24。第二个元素 'One' 在基数为 1 时被解析为 NaN。第三个元素 42 使用基数 2 进行解析。在基数 2 中，'42' 是 NaN，因此结果是 [24, NaN, NaN]。

这是 parseInt 和 map 的一个常见陷阱。如果你想将字符串数组解析为数字，唯一安全的“内置”方法是 .map(Number) 或添加回调/闭包 .map(x => parseInt(x, 10))。

Number 将值转换为数字类型比 parseInt 更严格。这里，'Twenty1' 变成 NaN，而 0o42 被识别为八进制字面量并转换为 34。

parseInt 会将输入强制转换为字符串，因此 null 变成 "null"。由于 "null" 没有有效的十进制字符（常规数字），所以它会返回 NaN。

Number(null) 返回 0，因为 JavaScript 就是喜欢让你措手不及。 为什么？嗯，如果有兴趣的话，我可以深入讲解。

由于 parseInt 总是将输入强制转换为字符串，null 变成了字符串 "null"。

在三十六进制（hexatrigesimal，如果你还记得的话）中，字符串 "null" 表示 1112745。

nulk、null 和 nulm 的连续值在三十六进制中分别是 1112744、1112745 和 1112746。