17370845950

JavaScript数字精度问题源于IEEE 754双精度浮点数无法精确表示十进制小数，如0.1+0.2≠0.3；解决需分场景：金融用decimal.js等高精度库，展示用toFixed()或Math.round()缩放，运算优先转整数；禁止直接用==/===比较浮点数，应采用误差容忍判断。

JavaScript 数字精度问题本质是二进制浮点数表示缺陷

JavaScript 所有数字都用 Number 类型（IEEE 754 双精度浮点数）存储，无法精确表示大多数十进制小数。比如 0.1 + 0.2 不等于 0.3，而是 0.30000000000000004。这不是 JS 独有，而是所有遵循 IEEE 754 的语言共性，但 JS 没有原生整数类型或小数类型，暴露更直接。

避免小数计算误差的三种实操路径

没有银弹，需按场景选：金融计算必须用高精度库；UI 展示可四舍五入；简单逻辑判断应改用整数运算。

• 金融/金额类计算：用 decimal.js 或 big.js，它们基于字符串实现十进制算术
  

  const Decimal = require('decimal.js');
  const a = new Decimal('0.1');
  const b = new Decimal('0.2');
  console.log(a.plus(b).equals('0.3')); // true

• 展示用的浮点结果：用 toFixed() 或 Math.round() 配合缩放，但注意它返回字符串，且 toFixed() 在某些浏览器对 1.005 会返回 "1.00"（非预期四舍五入）
  

  console.log((0.1 + 0.2).toFixed(1)); // "0.3"
  console.log(Math.round((0.1 + 0.2) * 10) / 10); // 0.3

• 能转整数就转整数：价格统一用“分”为单位，时间用毫秒，避免小数参与运算
  

  const priceInCents = 199; // 而不是 1.99
  const discountInCents = 20;
  const finalInCents = priceInCents - discountInCents; // 179 → 显示时除以 100

警惕 == 和 === 对浮点数的直接比较

直接用等号判断两个浮点运算结果是否相等，几乎必然出错。哪怕你用 toFixed() 处理过，返回的是字符串，和数字比较也会隐式转换出偏差。

• 永远不要写 if (a + b === 0.3)
• 改用误差容忍比较：Math.abs(a + b - 0.3) （EPSILON 约 2.22e-16，适合一般场景）
• 对业务敏感值（如金额），优先走整数比较或高精度库的 .equals() 方法

JSON 序列化和后端交互时精度可能二次丢失

JSON.stringify() 会把 Number 原样转成字符串，但若后端解析为 float/double，同样面临精度问题。尤其当 JS 传 { amount: 0.1 }，后端收到可能是 0.10000000000000000555。

• 前后端约定金额字段统一用字符串传输，例如 {"amount": "19.99"}
• 避免在 JS 中用 parseFloat() 解析后端返回的金额字符串，直接用高精度库构造
• 如果必须用数字，确保后端使用 BigDecimal（Java）、Decimal（Python）等十进制类型接收

实际项目里最容易被忽略的是：把 toFixed() 当作“修复精度”的万能解，但它只是格式化输出，内部值没变；还有就是测试时用整数常量验证逻辑，上线后换成用户输入的小数就崩了。