JavaScript中所有数字都是Number类型，底层用IEEE 754双精度浮点数表示，因此无法精确表示大多数十进制小数，如0.1+0.2!==0.3是设计所致而非bug。
JavaScript 中所有数字都是 Number 类型，底层用 IEEE 754 双精度浮点数表示 —— 这意味着它**天生无法精确表示大多数十进制小数**，比如 0.1 + 0.2 !== 0.3 是必然结果，不是 bug，是设计如此。
为什么 0.1 + 0.2 不等于 0.3？
因为 0.1 和 0.2 在二进制中都是无限循环小数（类似十进制里 1/3 = 0.333...），IEEE 754 只能截断存储，导致精度丢失。实际计算时：
console.log(0.1 + 0.2); // 0.30000000000000004
这不是 JavaScript 独有，Python、Java、C 等所有遵循 IEEE 754 的语言都一样。
常见误判场景：
立即学习“Java免费学习笔记（深入）”；
- 用
===直接比较浮点运算结果（如if (a + b === 0.3)） - 用
toFixed()后再转回数字做逻辑判断（parseFloat((0.1 + 0.2).toFixed(1)) === 0.3看似成立，但toFixed是字符串操作，隐式转换可能引入新误差） - 累计求和（如购物车价格累加）产生肉眼可见的偏差
安全比较浮点数：用 Number.EPSILON
Number.EPSILON 表示 1 与下一个可表示数字之间的差值（约 2.220446049250313e-16），是衡量“足够接近”的合理基准。
正确做法是判断两数之差是否小于某个容差值：
function floatEqual(a, b) {
return Math.abs(a - b) < Number.EPSILON;
}
console.log(floatEqual(0.1 + 0.2, 0.3)); // true注意：
- 对极大或极小数值，
Number.EPSILON可能不够用，此时应按数量级缩放容差（如Math.abs(a - b) ） - 不要用
==或===直接比浮点数
业务中避免误差的实用策略
真正需要精确计算的场景（如金融、计费），不依赖原生 Number 运算：
- 金额统一转为整数处理：所有价格以「分」为单位存
number，运算完再除以100格式化显示 - 使用可靠库：如
decimal.js（支持任意精度）、big.js（轻量、专为财务设计），它们内部用字符串+整数模拟运算 -
后端校验兜底：前端展示可容忍微小误差，但关键提交（如支付金额）必须由后端用高精度类型（如 Java
BigDecimal、PostgreSQLDECIMAL）二次校验 - 显示层用
toFixed(n)或Intl.NumberFormat控制小数位，但仅用于展示，不用于计算链路
最常被忽略的一点：误差会累积。哪怕单次运算误差在 EPSILON 内，连续做几十次加减乘除后，偏差可能放大到影响业务判断的程度。所以别只想着“修一个 0.1 + 0.2”，得从数据源头（单位）、计算路径（是否中间转字符串）、验证环节（前后端协同）整体控制。
