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 做安全的浮点数比较

直接用 === 比较浮点结果几乎总是错的。应改用“误差容忍”方式判断是否“足够接近”。

• Number.EPSILON 是 1 与下一个可表示数字之间的差值（约 2.220446049250313e-16），适合做相对误差基准
• 但注意：它只适用于数量级接近 1 的数；对很大或很小的数，需按比例缩放容差
• 更稳妥的做法是使用固定小数位容差（如金额场景常用 ±0.001）

function floatEqual(a, b, epsilon = 0.000001) {
  return Math.abs(a - b) < epsilon;
}
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 控制循环：i 会累积误差，可能跳过预期值或无限循环

这类场景建议改用整数步进：for (let i = 0; i 。