17370845950

JavaScript数字类型为64位双精度浮点数，导致0.1+0.2≠0.3；整数安全范围为±(2^53−1)；金额应转整数运算，浮点比较需用误差容忍。

JavaScript 的数字类型是 number，它统一用 64 位双精度浮点数（IEEE 754）表示整数和小数——这意味着它没有单独的 int 或 float 类型，也导致很多看似简单的计算会出人意料。

为什么 0.1 + 0.2 !== 0.3？

这是浮点数精度限制的直接体现：十进制小数 0.1 和 0.2 在二进制中是无限循环小数，存储时被截断，相加后误差累积，结果是 0.30000000000000004。

• 这不是 JavaScript 独有，所有遵循 IEEE 754 的语言（如 P

  

  ython、Java）都存在
• 整数在 -(2^53 - 1) 到 2^53 - 1 范围内可精确表示（即 Number.MAX_SAFE_INTEGER）
• 超过该范围的整数可能丢失精度，例如 9007199254740993 === 9007199254740992 返回 true

安全做数学计算的常用方式

取决于场景，没有“万能解”，但有明确取舍：

• 金额运算：一律转为整数（单位“分”），用 Math.round() 配合乘除，避免小数参与中间计算
• 比较浮点数：不用 ===，改用差值判断，例如 Math.abs(a - b)
• 大整数运算：超出 Number 安全范围时，改用 BigInt（注意：不能和 number 混用，否则报错 TypeError: Cannot mix BigInt and other types）
• 需要高精度小数（如科学计算）：引入第三方库如 decimal.js 或 big.js，它们用字符串或数组模拟运算

parseInt、parseFloat 和一元加号 + 的区别

三者都能转字符串为数字，但行为差异明显，容易误用：

• parseInt("12.99") → 12（只解析开头整数部分，遇到小数点就停）
• parseFloat("12.99px") → 12.99（能解析小数，但同样在非数字字符处停止）
• +"12.99" → 12.99（严格转换，任何非纯数字字符串都返回 NaN，如 +"12.99px"）
• 隐式转换（如 "12" * 1）也等价于一元加号，但可读性差，不建议用于关键逻辑

真正麻烦的不是“怎么算”，而是“什么时候该怀疑结果”。比如后端传来一个 ID 字符串 "90071992547409919"，前端用 Number 解析后可能变成 90071992547409920——这种精度丢失不会报错，却会在业务层面引发数据错乱。