JavaScript浮点数计算为何产生精度问题【教程】 返回列表

JavaScript浮点数计算符合IEEE 754标准，0.1+0.2≠0.3是因十进制小数无法精确转二进制，导致存储近似值及误差叠加；整数在±2^53内精确，小数几乎总为近似；金额运算、数组去重、循环条件、前后端比对等场景必须处理误差；常用策略包括toFixed四舍五入、转整数运算、使用decimal.js等库或误差容忍比较。

JavaScript 中的浮点数计算不是“出错了”，而是严格按照 IEEE 754 双精度标准执行的结果——所有看似奇怪的 0.1 + 0.2 !== 0.3 都是这个标准下的必然表现。

为什么 0.1 在 JavaScript 里存不准

十进制小数 0.1 无法用有限位二进制精确表示，就像十进制下 1/3 = 0.333... 是无限循环小数一样。IEEE 754 只能截断或舍入，导致实际存储的是近似值：

console.log(0.1.toFixed(17)); // "0.10000000000000001"

• 0.1 和 0.2 各自都有微小误差，相加后误差叠加，结果变成 0.30000000000000004
• 所有基于 IEEE 754 的语言（Python、Java、C++）都存在同样问题，不是 JS 独有
• 整数在 -(2^53) ~ 2^53 范围内可安全精确表示，但小数几乎总是近似

哪些场景必须处理浮点误差

不是所有计算都需要干预，但以下情况不处理会直接引发业务问题：

• 金额运算（如 price + tax）——用户看到 19.99 + 0.17 = 20.160000000000004 会质疑系统可靠性
• 数组去重或对象键名生成（{[0.1 + 0.2]: 'x'} 和 {[0.3]: 'x'} 实际是两个不同 key）
• 循环条件（for (let i = 0; i !== 1; i += 0.1) 可能死循环）
• 与后端或数据库比对（如 SQL 查询 WHERE amount = 12.34，JS 传过去却是 12.340000000000002）

实用的修复策略和取舍

没有银弹，选哪种方式取决于场景和精度要求：

• 显示层四舍五入：parseFloat((0.1 + 0.2).toFixed(2)) —— 简单有效，但仅适用于展示，不能用于后续计算
• 转整数运算：把元转为分，(1999 + 17) / 100 → 20.16，彻底规避小数
• 使用库如 decimal.js 或 big.js：适合金融级精

  

  度，但引入额外体积和运行时开销
• 容忍误差比较：Math.abs(a - b) 替代 a === b，注意 Number.EPSILON 是 2^-52，对大数不适用，此时应按比例缩放

最容易被忽略的坑

很多人修了显示，却忘了数据流转的其他环节：

• JSON.stringify() 会自动把 0.1 + 0.2 序列化成 0.30000000000000004，前端传给后端前必须格式化
• Number('0.1') 和 parseFloat('0.1') 结果相同，但字符串解析本身不解决存储精度，只是输入阶段的转换
• 使用 toFixed() 后得到的是字符串，再参与计算会隐式转回 number，误差又回来了
• 像 0.1 + 0.2 === 0.3 这类判断，在单元测试里必须用误差范围断言，否则 CI 会偶然失败