JS四舍五入保留两位小数：为什么toFixed不准及修复方案

一、现象重现：toFixed 到底在哪些场景下会“失真”？

为了具体观察 toFixed 的表现，可以在浏览器的控制台中运行以下这组简单的小数四舍五入测试：

// 期望保留两位小数，末位为 5 时标准四舍五入应进位
console.log((1.005).toFixed(2)); // 输出: "1.00" （预期: "1.01" ❌ 舍弃了）
console.log((1.015).toFixed(2)); // 输出: "1.01" （预期: "1.02" ❌ 舍弃了）
console.log((1.025).toFixed(2)); // 输出: "1.03" （预期: "1.03"  进位了）
console.log((1.035).toFixed(2)); // 输出: "1.04" （预期: "1.04"  进位了）
console.log((1.045).toFixed(2)); // 输出: "1.04" （预期: "1.05" ❌ 舍弃了）
console.log((3.555).toFixed(2)); // 输出: "3.55" （预期: "3.56" ❌ 舍弃了）

从这组测试中可以看出，末位同为 5，有时向上进位，有时却向下舍去。如果在电商结算、计费对账、分摊提成等场景下直接依赖 toFixed(2)，就会导致页面显示的金额与数据库计算结果相差 1 分钱，进而引发用户客诉与对账不平的问题。

二、根本原因：IEEE 754 浮点转换与底层存储真相

JavaScript 中的所有数字（除了 BigInt）都是基于 IEEE 754 标准的 64 位双精度浮点数（Double Precision Float）存储的。

我们人类使用的十进制是逢十进一，而计算机底层只能处理逢二进一的二进制。在十进制里能够简短表示的小数（如 0.1 或 0.005），在转换为二进制时却极易变成无限循环小数。

以 1.005 为例，将其拆解为整数部分 1 和小数部分 0.005。根据十进制小数转二进制的“连续乘 2 取整法”：

• 0.005 × 2 = 0.010 （整数部分为 0）
• 0.010 × 2 = 0.020 （整数部分为 0）
• 0.020 × 2 = 0.040 （整数部分为 0）
• 0.040 × 2 = 0.080 （整数部分为 0）
• 0.080 × 2 = 0.160 （整数部分为 0）
• 0.160 × 2 = 0.320 （整数部分为 0）
• 0.320 × 2 = 0.640 （整数部分为 0）
• 0.640 × 2 = 1.280 （整数部分为 1，剩余 0.28）
• 0.280 × 2 = 0.560 （整数部分为 0）……

这个乘 2 的过程永远无法归零，计算得到的是一个无限循环的二进制小数：0.000000010100011110101110000101...。

然而，64 位双精度浮点数的硬件寄存器只有固定的位宽分配：

1. 符号位（Sign bit）：1 位，代表正负号；
2. 阶码位（Exponent）：11 位，带偏移量（1023）；
3. 尾数位（Mantissa/Fraction）：52 位，用于存储有效数字。

当无限循环的二进制尾数超出 52 位容量时，计算机必须执行截断和硬件层面的舍入（Round-to-nearest）。这导致 1.005 在内存中实际记录的精确十进制还原数值是：

1.004999999999999893418589635985...

当调用 (1.005).toFixed(2) 时，算法并非依据代码里肉眼看到的 1.005 裁决，而是基于内存中的实际存储值 1.00499999999999989... 进行四舍五入。由于从小数点后第三位开始的值是 4，严格符合“小于 5 舍去”的数学法则，于是顺理成章地舍去后面的部分，最终输出了 "1.00"。

三、破除迷思：toFixed 真的使用了“银行家舍入法”吗？

在技术社区中，有一种非常常见的说法：“toFixed 采用的是银行家舍入法（四舍六入五成双：遇到 5 时，如果前一位是奇数则进位，若前一位是偶数则舍去以求得偶数）”。这种说法是不准确的。

我们可以直接用实测反例推翻这一假设：

• 若严格遵循银行家舍入，(1.015).toFixed(2) 中 5 前面是奇数 1，应当进位为 "1.02"；但实测输出却是 "1.01"；
• (1.025).toFixed(2) 中 5 前面是偶数 2，若按银行家法则应舍去保留偶数 "1.02"；但实测输出却是 "1.03"。

查阅 ECMAScript 规范关于 Number.prototype.toFixed(fractionDigits) 的定义，规范设计的本质就是标准的数学四舍五入（寻找最接近的十进制分数，遇到等距则取较大值）。其之所以表现得时进时舍、毫无规律，根本原因在于输入参数在进入舍入流程前，其精度已经在浮点数转换中发生随机偏差：

四、方案对比与修复实现

常见误区：为什么 Math.round(num * 100) / 100 仍然不靠谱？

很多开发者在意识到 toFixed 不准后，会尝试使用乘以 100 再取整的传统写法：

// 尝试使用乘法取整
function badRound(num) {
  return Math.round(num * 100) / 100;
}

console.log(badRound(1.005)); // 依然输出 1，而不是 1.01！

这是因为 JavaScript 在执行浮点数乘法 1.005 * 100 时，计算结果直接变成了 100.49999999999999。Math.round(100.49999999999999) 计算后得到的整数依然是 100，再除以 100 还是 1，根本问题完全没有解决。

方案一：科学计数法平移法（通用推荐，0 外部依赖）

为了规避浮点数直接乘除带来的二次精度损失，业界最经典、轻量且高效的做法是使用科学计数法指数平移法（Exponential Shift）。

该方案的执行逻辑分为四步：

1. 指数正向平移：利用字符串拼接将数字变为科学计数法 1.005e2，此时 JavaScript 解析器直接将小数点右移两位转换为 100.5，避免了乘法浮点误差；
2. 整数四舍五入：调用 Math.round(100.5)，在纯净的小数点后一位执行标准四舍五入，稳健进位得到整数 101；
3. 逆向指数平移：拼接负指数 101e-2，将小数点安全回移两位，得到精确数值 1.01；
4. 格式化补零：最后调用原生 toFixed(decimals) 补充尾随的零（如保证 1.1 输出 "1.10"）。

完整工程级封装代码如下：

/**
 * 严谨四舍五入保留指定位数小数（基于科学计数法平移）
 * @param {number|string} value 需要处理的数值
 * @param {number} decimals 保留的小数位数，默认 2
 * @returns {string} 格式化后的字符串
 */
function roundTo(value, decimals = 2) {
  if (value === null || value === undefined || isNaN(Number(value))) {
    return "0.00";
  }
  
  // 将输入转换为数字字符串形式
  const numStr = String(value);

  // 第一步与第二步：利用科学计数法指数右移并取整
  // 例如 "1.005e+2" -> 100.5 -> Math.round 得到 101
  const rounded = Math.round(Number(numStr + 'e' + decimals));

  // 第三步与第四步：逆向移回小数点并固定小数位数补零
  // "101e-2" -> 1.01 -> "1.01"
  return Number(rounded + 'e-' + decimals).toFixed(decimals);
}

// --- 验证效果 ---
console.log(roundTo(1.005, 2)); // 输出: "1.01"  精准进位
console.log(roundTo(1.015, 2)); // 输出: "1.02"  精准进位
console.log(roundTo(1.045, 2)); // 输出: "1.05"  精准进位
console.log(roundTo(3.555, 2)); // 输出: "3.56"  精准进位
console.log(roundTo(1.1, 2));   // 输出: "1.10"  自动补零
console.log(roundTo(2, 2));     // 输出: "2.00"  自动补零

方案二：Number.EPSILON 补偿法

ES6 引入了 Number.EPSILON，代表 1 与大于 1 的最小浮点数之间的差值（约为 2.220446049250313e-16），本质上是 JavaScript 能识别的最小精度差。

对于正数，可以在乘法取整前加上一个微小的补偿量，将被截断成 1.00499999999999989 的数值轻微推向 1.0050000000000001，从而让 Math.round 正常进位：

function roundWithEpsilon(num, decimals = 2) {
  const factor = Math.pow(10, decimals);
  return (Math.round((num + Number.EPSILON) * factor) / factor).toFixed(decimals);
}

console.log(roundWithEpsilon(1.005, 2)); // 输出: "1.01"

注意局限：Number.EPSILON 适合常规范围内的正数格式化。如果涉及负数，补偿方向需反转；在极大数或多步复合运算的场景下，由于绝对尺度增大，固定常数 EPSILON 的补偿效果会逐渐失效。

方案三：金融与财税级场景（Big.js / Decimal.js）

如果业务属于电商核心下单、支付清结算、银行外汇或税务对账，单靠在最后展示阶段做四舍五入是远远不够的。在“单价 × 数量 - 优惠券分摊 + 运费税费”的多步连续计算中，二进制浮点误差会在中间运算中层层放大。

在此类严谨场景下，必须自始至终使用基于纯字符串/大数数组实现的高精度十进制运算库（如 big.js 或 decimal.js）。

// 引入 big.js（仅约 6KB，专为金额设计）
import Big from 'big.js';

// 指定四舍五入规则：ROUND_HALF_UP 代表标准数学四舍五入
Big.RM = Big.roundHalfUp;

const price = new Big('1.005');
const total = price.toFixed(2);

console.log(total); // 输出: "1.01" （绝对精确，无视硬件浮点限制）

五、业务选型与技术决策指南

在实际工程落地中，没有绝对完美的方案，只有契合业务场景和团队成本的最优解：

六、总结提炼

1. 本质认识：(1.005).toFixed(2) === "1.00" 的根源是十进制小数 0.005 无法被 IEEE 754 64位浮点数精确表示，底层实际存放为 1.004999...，算法并没有写错，是输入值偏小了。
2. 破除流言：toFixed 不是银行家舍入，其规范本意是数学四舍五入，切勿误信奇偶规则来编写补丁代码。
3. 工程落地：前端常规格式化两位小数，推荐直接使用科学计数法指数平移函数 roundTo；若涉及财务账目多步复合运算，全链路必须采用 big.js 进行十进制计算，并在最终输出时统一舍入。