javascript浮点数计算不精确是ieee 754标准导致的共性问题，0.1+0.2结果为0.30000000000000004而非0.3；应使用误差容忍法（如number.epsilon或自定义容差）替代===比较。
JavaScript 的浮点数计算不精确，不是 bug，而是 IEEE 754 双精度浮点数标准在所有遵循该标准的语言（包括 Python、C、Java）中的共性表现。0.1 + 0.2 === 0.3 返回 false 就是最典型的信号。
为什么 0.1 + 0.2 !== 0.3？
因为十进制小数 0.1 和 0.2 在二进制中是无限循环小数，无法被 Number 类型（64 位双精度）精确表示。它们被截断存储后，加法结果产生微小误差：0.1 + 0.2 实际得到的是 0.30000000000000004。
这不是 JavaScript 特有，但 JS 没有原生 decimal 类型，开发者更容易踩坑。
用 Number.EPSILON 做安全的浮点数比较
直接用 === 比较浮点结果几乎总是错的。应改用“误差容忍”方式判断是否“足够接近”。
立即学习“Java免费学习笔记（深入）”；
-
Number.EPSILON是 1 与下一个可表示数字之间的差值（约2.220446049250313e-16），适合做相对误差基准 - 但注意：它只适用于数量级接近 1 的数；对很大或很小的数，需按比例缩放容差
- 更稳妥的做法是使用固定小数位容差（如金额场景常用 ±0.001）
function floatEqual(a, b, epsilon = 0.000001) {
return Math.abs(a - b) < epsilon;
}
<p>floatEqual(0.1 + 0.2, 0.3); // true
floatEqual(1000000.1 + 0.2, 1000000.3); // 仍可靠（因 epsilon 显式指定）处理金额等关键数据：别转字符串再 parseFloat
常见错误是把钱转成字符串再切小数位，比如 parseFloat((0.1 + 0.2).toFixed(1))——这看似修复了显示，但 toFixed 本身也受浮点误差影响，且会四舍五入引入新偏差。
- 正确做法：全程用整数（单位为“分”）运算，例如
10 + 20 === 30（单位：分），最后才除以 100 显示 - 若必须用小数，用专门库如
decimal.js或big.js，它们基于字符串实现十进制算术 - 避免
Math.round(x * 100) / 100：当x是0.015这类边界值时，x * 100可能变成1.4999999999999998，导致错误舍入
哪些操作会放大浮点误差？
误差本身很小（~1e-16），但在多次迭代或特定运算中会被显著放大：
- 累加大量小浮点数（如统计传感器数据）：误差随次数线性增长
- 减法抵消（catastrophic cancellation）：两个相近大数相减，有效位数急剧丢失，例如
9999999999999999 - 9999999999999998得到0（因精度不够存不下 1） - 使用
for (let i = 0; i 控制循环：<code>i会累积误差，可能跳过预期值或无限循环
这类场景建议改用整数步进：for (let i = 0; i 。
