JavaScript数字是IEEE 754双精度浮点数，0.1+0.2≠0.3是标准特性而非bug；金融场景应统一用整数单位（如“分”）运算，小数运算推荐decimal.js并严格用字符串初始化。
JavaScript 中的数字是双精度浮点数（IEEE 754），0.1 + 0.2 !== 0.3 不是 bug，而是所有遵循该标准的语言共有的表现。想“精确”操作小数，不能靠绕开或忽略，得靠明确策略。
为什么 parseFloat 和直接相加解决不了精度问题
很多人试过用 parseFloat((0.1 + 0.2).toFixed(10)) 或先转字符串再解析，但这些只是掩盖了底层表示——toFixed 返回字符串，再转回数字又会重新触发浮点转换；parseFloat 本身不改变 IEEE 754 的存储逻辑。
-
0.1在二进制中是无限循环小数，无法被精确表示 -
Number.EPSILON只能用于比较是否“足够接近”，不能修复计算结果 - 任何涉及
+、-、*、/的原始数字运算都走浮点路径
金融/计费场景：统一用整数单位（如「分」）运算
这是最可靠、零依赖、无兼容性风险的做法。把用户看到的「元」全部放大 100 倍存为整数，所有加减乘除都在整数域完成。
- 输入时：
parseInt((userInput * 100).toFixed(0))—— 注意必须先toFixed(0)截断小数位，再parseInt，否则parseFloat("19.999999999999996")可能误入 - 显示时：
(cents / 100).toFixed(2)—— 保证两位小数输出，不依赖四舍五入逻辑 - 乘法需额外处理：
(amountInCents * 123) / 100是错的，应写成Math.round((amountInCents * 123) / 100)防止除法引入新误差
需要小数运算时：用 decimal.js 而非 big.js 或手写
big.js 舍入模式少、不支持科学计数法解析；bignumber.js 功能全但 API 繁重；decimal.js 在精度控制、舍入策略（ROUND_HALF_UP 等）、JSON 序列化支持上更贴近实际业务需求。
立即学习“Java免费学习笔记（深入）”；
- 初始化必须用字符串：
new Decimal("0.1").plus("0.2")—— 传数字字面量如new Decimal(0.1)会立刻丢失精度 - 链式调用默认不修改原实例：
a.plus(b).times(c)安全，无需担心污染 - 除法必须指定精度：
a.div(b, 10)表示保留 10 位小数，否则可能无限循环（如1/3）
日常开发中容易被忽略的隐式转换点
很多精度问题不是出在显式计算，而是藏在类型转换里：
-
input.value是字符串，但+input.value会触发Number()转换 —— 改用parseFloat(input.value)至少能多一层可控解析 -
JSON.parse('{ "price": 19.99 }')没问题，但JSON.stringify({ price: 0.1 + 0.2 })输出的是"0.30000000000000004" -
Array.prototype.reduce初始值写0没问题，但如果初始值是0.0或从接口来的number，后续累加就进入浮点轨道
真正难的不是选哪个库，而是识别哪些字段必须保精度、哪些可以容忍误差。一旦开始混合使用整数运算和 decimal.js，边界处的类型检查和转换就很容易漏掉——比如后端返回的金额是字符串还是数字，前端没校验就直接喂给 Decimal，反而引入新问题。