javascript数字精度问题本质是ieee 754双精度浮点数无法精确表示多数十进制小数，如0.1+0.2≠0.3；tofixed()返回字符串、仅格式化输出、不解决底层精度问题，且四舍五入不符合金融要求；推荐整数运算（如金额转“分”）或number.epsilon近似比较。
JavaScript 数字精度问题的本质是什么
JavaScript 中所有数字都是 Number 类型，底层用 IEEE 754 双精度浮点数表示（64 位），这意味着它无法精确表示很多十进制小数，比如 0.1 + 0.2 !== 0.3。这不是 bug，而是浮点数的固有局限——二进制无法有限表达大多数十进制小数。
toFixed() 为什么不能直接用于精度比较或计算
toFixed() 返回的是字符串，不是数字；且它会四舍五入（非银行家舍入），在边界值上可能引发意外结果。更关键的是：它不改变原始值的存储精度，只是格式化输出。
- 调用
(0.1 + 0.2).toFixed(1)得到"0.3"，但parseFloat((0.1 + 0.2).toFixed(1)) === 0.3仍为false（因 parseFloat 解析后又回归浮点表示） - 对负数使用时行为易混淆：
(-0.5).toFixed(0)返回"-0"，而非"0" - 在金融类场景中，
toFixed()的四舍五入不符合会计要求（如需“四舍六入五成双”）
可靠处理精度的实用方案
没有银弹，但可根据场景选合适策略：
- 整数运算优先：金额统一转为“分”（乘 100），全程用整数加减，最后再除以 100 显示。这是最稳妥的做法
-
使用
Number.EPSILON做近似比较：判断相等应写成Math.abs(a - b) ，而不是 <code>a === b -
需要高精度计算时引入库：如
decimal.js或big.js，它们用字符串+整数模拟任意精度，适合计算器、金融系统 -
显示层用 toFixed() + parseFloat() 要谨慎：若必须用，建议先
Math.round(x * 100) / 100再格式化，避免浮点残留影响显示
const a = 0.1 + 0.2; console.log(a); // 0.30000000000000004 console.log(Math.abs(a - 0.3) < Number.EPSILON); // true console.log(Math.round(a * 100) / 100); // 0.3
parseInt() 和 parseFloat() 的陷阱
这两个函数在处理带字母的字符串时会静默截断，且不校验后续非法字符；更严重的是，parseInt() 默认按八进制解析以 0 开头的字符串（ES5 以前），现在虽已修正，但未指定基数仍是隐患。
立即学习“Java免费学习笔记（深入）”；
-
parseInt("10.99")→10（只取整数部分） -
parseInt("089")在旧环境可能得0（误当八进制），应始终写parseInt("089", 10) -
parseFloat("12.34.56")→12.34（遇到第二个小数点就停） - 推荐替代：用
Number(str)或一元加号+str，它们对非法输入返回NaN，更易检测错误
浮点精度问题不会消失，关键是别把它当成“要修的 bug”，而是当作和时间、时区、字符编码一样需要主动建模的系统约束。真正容易被忽略的，是把 toFixed() 当作计算工具用——它只负责“说”，不管“算”。
