javascript算术运算符因基于ieee 754浮点数导致精度丢失，误差会累积；可靠方案是转整数运算、用bignumber.js等高精度库或后端统一计算。
JavaScript 的算术运算符（+、−、*、/、%、**）本身不处理精度丢失，它们直接在 IEEE 754 双精度浮点数上运算，而这种底层表示方式天然无法精确存储多数十进制小数（如 0.1、0.2），所以结果必然带误差。
为什么算术运算符会放大精度问题
因为每个运算步骤都基于已有浮点近似值继续计算，误差会累积或传播：
-
0.1 + 0.2不是“先算再舍入”，而是两个本就不精确的二进制近似值相加，结果仍是近似值0.30000000000000004 -
0.3 - 0.1同样使用0.3的近似存储值减去0.1的近似存储值，不是理想数学减法 -
toFixed(2)只是字符串格式化，不修正内部数值；它对0.615返回"0.61"是因为内部实际值略小于0.615，四舍五入逻辑按真实二进制值判断
常见但无效的“修复”误区
这些做法看似合理，实则治标不治本：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用
parseFloat((a + b).toFixed(n))：只是截断显示，原始计算误差仍在，且toFixed本身有舍入偏差 - 手动加减
Number.EPSILON：无法系统性解决，不同量级误差需不同容差，易引入新错误 - 依赖
Math.round(a * 100) / 100：对0.1 + 0.2有效，但对0.28 * 100（得27.999999999999996）仍失败
真正可靠的应对策略
核心思路是避开浮点数参与关键中间计算：
-
转整数运算：把元换成分、米换成毫米、百分比乘 100，全程用整数加减乘除，最后再除回去。例如价格计算：
(100 + 200) / 100 → 3.00 -
用高精度库统一接管：如
bignumber.js或decimal.js，所有数字用字符串初始化（new BigNumber('0.1')），所有运算调用其方法（.plus()、.times()） -
后端统一计算：前端只传原始数据（如字符串
"0.1"、"0.2"），由后端用BigDecimal等高精度类型执行并返回结果，避免前后端不一致
何时可以忽略精度问题
并非所有场景都需要高精度：
- 动画插值、图形坐标偏移等视觉类计算，人眼不可察的微小误差可接受
- 非金融类统计（如用户停留时长均值），保留 1–2 位小数即可，可用
toFixed(2)配合parseFloat做展示层处理 - 大整数比较（如 ID、时间戳）只要不超过
Number.MAX_SAFE_INTEGER（9007199254740991），加减不会出错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
