javascript浮点数误差源于二进制无法精确表示0.1等十进制小数，ieee 754双精度截断导致偏差；金额计算应转为整数（如“分”）运算，高精度场景用decimal.js或bignumber.js（字符串初始化），展示与比较可用tofixed或容差法。
JavaScript 中浮点数计算误差无法完全消除，但可以通过合适的方法规避实际影响。核心在于理解误差来源——0.1、0.2 等十进制小数在二进制中是无限循环小数，而 IEEE 754 双精度浮点数只有 53 位尾数，必须截断，导致存储和运算结果出现微小偏差（如 0.1 + 0.2 === 0.30000000000000004）。
金额类计算：统一转为整数单位运算
这是金融、电商等对精度零容忍场景的首选方案，简单、可靠、无依赖。
- 所有金额以“分”为单位存储和参与计算，例如
19.90 元 → 1990 分 - 加减乘除全程使用整数，不涉及小数
- 最终展示时再除以 100，并用
toFixed(2)格式化（注意仅用于显示） - 示例：
const totalCents = 1990 * 3; // 5970；const totalYuan = (totalCents / 100).toFixed(2); // "59.70"
通用高精度计算：引入 decimal.js 或 bignumber.js
当业务涉及科学计算、多步小数运算、或需保留多位小数（如利率、汇率）时，推荐使用成熟高精度库。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
decimal.js专为十进制设计，行为更贴近人类直觉，支持自定义精度和舍入模式 -
bignumber.js更轻量，API 简洁，适合大多数精度敏感场景 - 用字符串初始化避免初始精度污染：
new Decimal('0.1').plus('0.2').toString()→'0.3' - 避免混用原生数字：
new Decimal(0.1)仍会继承原始误差，应写成new Decimal('0.1')
展示与比较：用容差或格式化代替直接判断
若只需用户看到正确结果，或做近似相等判断，无需改变底层数值类型。
- 显示金额：
(0.1 + 0.2).toFixed(2)→"0.30"（返回字符串，注意后续不可再运算） - 安全比较：
Math.abs(a - b) 或自定义容差（如 <code>1e-10） - 避免
===直接比浮点数：0.1 + 0.2 === 0.3永远为false - 如需转回数字且保留两位小数，可用
parseFloat((x).toFixed(2))
慎用技巧：避免常见误区
有些看似取巧的方法反而引入新问题，需特别注意。
-
toFixed()不是计算方法，它只处理显示；且对1.335这类数可能不按数学四舍五入（因内部二进制表示） - 简单乘除缩放（如
Math.round((a * 100 + b * 100) / 100)）在大数时易溢出，且不能覆盖所有运算组合 -
BigInt仅适用于整数，不能直接处理小数；0.1n语法非法 - 连续多次
toFixed+parseFloat嵌套会累积舍入误差，不推荐
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
