JavaScript金融四舍五入不准的根源是IEEE 754浮点数不满足十进制精度要求，正确做法是用整数单位（分）运算或decimal.js等十进制库。
JavaScript 中的四舍五入不是“错”，而是和金融场景需要的精度标准不一致。根本问题在于：JS 默认用 IEEE 754 双精度浮点数做运算，而金融计算要求严格十进制行为——比如 1.255 四舍五入到两位小数必须是 1.26，但 Math.round(1.255 * 100) / 100 很可能返回 1.25。
toFixed() 看似方便，实则暗藏兼容性风险
它返回字符串，且在不同浏览器中对“0.5”类临界值的处理曾不统一（如 Chrome 用银行家舍入，旧 IE 用传统四舍五入）。即使现在趋于标准化，(0.55).toFixed(1) 在部分环境仍可能得 "0.5" 而非 "0.6"。若后续要参与计算，必须转回数字：parseFloat("0.6") 或 +(0.55).toFixed(1)，但转换本身无法修复原始浮点误差。
手动放大取整法更可控，但需防浮点污染
核心思路是把小数位移出去，整数化后再缩回。例如保留两位小数：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 先乘 100 → 得到近似整数（但可能已是 125.49999999999999）
- 加
Number.EPSILON再Math.round，可抵消部分截断误差：Math.round((num * 100) + Number.EPSILON) / 100 - 对负数需额外处理符号，建议封装为函数并统一测试边界值（如 -1.255、0.005）
金融级计算必须绕开浮点数本身
真正可靠的方案不是“修 rounding”，而是换数据表示方式：
- 金额全程用整数单位（分、厘）运算，避免任何小数参与中间过程
- 引入
decimal.js或big.js：它们以字符串解析数字，内部用十进制逻辑运算，new Decimal('1.255').round(2).toString()稳定输出"1.26" - 后端返回金额字段应优先用字符串或整数，前端不做原始 parseFloat
不复杂但容易忽略：四舍五入只是表象，根源是 JS 的数字类型不适合金融计算。选对底层表示，比调一百次 toFixed 更治本。
