JavaScript 中 toFixed() 方法看似不一致的舍入行为解析-js教程-PHP中文网

toFixed() 的“忽上忽下”并非 Bug，而是浮点数二进制表示固有精度限制导致的必然现象——所有看似以 .5、.05、.005 结尾的十进制小数，在 IEEE 754 双精度格式中往往无法精确存储，实际参与计算的是其最接近的二进制近似值，进而影响舍入判定。

javascript 中 `tofixed()` 的“忽上忽下”并非 bug，而是浮点数二进制表示固有精度限制导致的必然现象——所有看似以 `.5`、`.05`、`.005` 结尾的十进制小数，在 ieee 754 双精度格式中往往无法精确存储，实际参与计算的是其最接近的二进制近似值，进而影响舍入判定。

toFixed() 方法常被误认为执行“四舍五入”，但其规范行为实为向最近的可表示数值舍入（round half to even 的变体），前提是输入能被精确表示。然而，JavaScript 中几乎所有小数（除有限二进制小数如 0.5、0.25 外）都存在精度损失。例如：

console.log(0.05.toFixed(1)); // '0.1' → 表面看是向上舍入
console.log(2.05.toFixed(1)); // '2.0' → 表面看是向下舍入

根本原因在于：

0.05 在二进制中是无限循环小数 0.000011001100110011...₂，JS 实际存储的是略大于 0.05 的值（如 0.05000000000000002）；
2.05 同样无法精确表示，但其二进制近似值可能略小于 2.05（如 2.0499999999999998）；
toFixed(n) 内部将数字转换为字符串前，先按 IEEE 754 规则进行舍入运算，而输入值本身的微小偏差直接决定了最终舍入方向。

可通过 Number.EPSILON 和 toPrecision() 验证这种隐式误差：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

console.log((2.05).toPrecision(17)); // "2.0499999999999998"
console.log((8.05).toPrecision(17)); // "8.0500000000000007"

可见，2.05 实际略小，舍入到十分位时 0.049... 小于 0.05，故向下取整为 '2.0'；而 8.05 实际略大，0.050... 大于 0.05，故向上取整为 '8.1'。

✅ 正确应对策略：

✦ 避免依赖 toFixed() 做金融/科学计算：改用整数运算（如金额统一转为分）、或引入 decimal.js / big.js 等高精度库；

✦ 需显示舍入时，先手动修正浮点误差：

function toFixedSafe(num, digits) {
  const factor = Math.pow(10, digits);
  return (Math.round(num * factor) / factor).toFixed(digits);
}
console.log(toFixedSafe(2.05, 1)); // '2.1' —— 符合直觉的四舍五入