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）
实用的修复策略和取舍
没有银弹，选哪种方式取决于场景和精度要求：
立即学习“Java免费学习笔记（深入）”；
- 显示层四舍五入：
parseFloat((0.1 + 0.2).toFixed(2))—— 简单有效，但仅适用于展示，不能用于后续计算 - 转整数运算：把元转为分，
(1999 + 17) / 100→20.16，彻底规避小数 - 使用库如
decimal.js或big.js：适合金融级精度，但引入额外体积和运行时开销 - 容忍误差比较：
Math.abs(a - b) 替代 <code>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 会偶然失败
