金融场景中javascript浮点误差是必然问题，必须用“分”为单位的整数运算或decimal.js等高精度库处理，前后端需统一字符串传参和十进制计算。
金融场景下，JavaScript浮点数计算误差不是“偶尔出错”，而是必然发生、可预见、必须拦截的问题。0.1 + 0.2 ≠ 0.3 这类现象背后是IEEE 754双精度存储机制的固有局限，一旦进入金额计算、利息分摊、税费折算、对账校验等环节，微小误差会逐级放大——百万订单可能差出数万元，日结报表可能总和不等于100%。
用整数单位代替小数单位
最简单、最可靠、零依赖的方案：所有金额统一以“分”为单位参与运算，全程使用整数加减乘除。
- 商品标价99.99元 → 存储为9999（单位：分）
- 优惠券减5元 → 转为500分后参与计算
- 最终展示前再除以100，并用 Number.toFixed(2) 格式化（注意：仅用于展示，不可用于后续计算）
该方式彻底避开小数二进制表示问题，适用于收银、购物车、发票生成等绝大多数前端金融逻辑。
避免 toFixed() 直接转数字用于计算
toFixed() 返回字符串，且采用银行家舍入（四舍六入五成双），直接 parseFloat('1.005'.toFixed(2)) 得到的是 1.00，而非预期的1.01——这在税务、利息四舍五入场景中极易引发合规风险。
- 展示用：
'1.005'.toFixed(2)→"1.00"（符合会计规范时可用） - 计算用：必须先转为整数单位，或使用高精度库处理原始值
- 如需自定义舍入规则（如强制向上/向下/四舍五入），应调用 decimal.js 的 toDecimalPlaces(n, Decimal.ROUND_HALF_UP) 等方法
关键路径必须用高精度库兜底
涉及多步运算、复合公式（如年化利率、复利、阶梯折扣）、或与后端返回小数交互的场景，整数方案难以覆盖，此时应引入成熟高精度库。
- decimal.js：API丰富、精度可控、支持多种舍入模式，适合复杂金融逻辑（推荐用于利息计算、风控评分）
- bignumber.js：轻量、兼容性好、Node.js与浏览器通吃，适合支付核对、大额资金运算
- 务必用字符串初始化：
new Decimal('0.1').plus('0.2')，避免new Decimal(0.1)从源头继承浮点误差
前后端统一精度策略，杜绝隐性偏差
前端用 decimal.js 算出 107.9892，后端用 double 类型计算得 107.98919999999999，对账就会失败。精度问题从来不是单端问题。
- 约定接口字段全部传字符串格式金额（如
"99.99"、"107.9892"），禁止传 number - 后端也应使用 BigDecimal（Java）、Decimal（Python/C#）等十进制类型做运算
- 建立金额一致性校验：前端计算结果与后端返回结果比对时，用 Decimal.equals() 或误差容限
Math.abs(a.minus(b).toNumber())
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
