为什么JS的toFixed四舍五入不准确及修复方案

缩略概览：toFixed 异常表现与修复核心链路

一、现象直击：toFixed 的不确定舍入表现

在日常业务中，格式化展示商品价格或利率时，开发者经常直接调用 toFixed(2)。但稍加测试便会发现令人困惑的结果：

// 浏览器控制台运行示例
console.log((1.005).toFixed(2)); // 输出示例: "1.00" （末尾 5 消失，未进位）
console.log((1.015).toFixed(2)); // 输出示例: "1.01" （末尾 5 未进位）
console.log((1.025).toFixed(2)); // 输出示例: "1.03" （成功进位）
console.log((1.035).toFixed(2)); // 输出示例: "1.04" （成功进位）
console.log((1.045).toFixed(2)); // 输出示例: "1.04" （末尾 5 未进位）
console.log((1.055).toFixed(2)); // 输出示例: "1.05" （末尾 5 未进位）

许多开发者在遇到上述现象时，第一反应往往是“JavaScript 采用了银行家舍入法（四舍六入五成双）”。所谓的“五成双”，是指当舍入位正好是 5 时，根据前一位的奇偶性决定：奇数进位，偶数舍去。然而观察上面的例子，1.005 保留两位时，前一位是 0（偶数），舍去得到 1.00；但 1.045 前一位是 4（偶数），却舍去得到 1.04；而 1.015 前一位是 1（奇数），舍去得到 1.01（若按五成双本应进为 1.02）。

显然，这与银行家舍入法的规则完全相悖。事实是：ECMAScript 规范定义的 toFixed 并不是银行家舍入，而是在底层数据失真影响下的近似舍入。

二、原因剖析：底层存储与规范执行的双重影响

要搞清为什么舍入不准，必须从数字在内存中的形态和规范计算步骤两个层面来看。

1. IEEE 754 双精度浮点数存储机制

JavaScript 内部所有数字均以 64 位双精度浮点数（IEEE 754 标准）存储。计算机底层是二进制的，十进制中的有限小数在转为二进制时往往是无限循环小数。例如十进制的 0.1 或 0.005：

0.005 转换二进制的过程为：乘以 2 取整数部分，产生无限循环序列 0.00000001010001111010111...。由于 64 位浮点数只有 52 位用于表示有效数字尾数（Significand），超出部分只能在末尾截断。

截断的结果就是：我们肉眼看到的 1.005，在计算机内存中实际存放的值是 1.004999999999999893418589635985...。

图 1：IEEE 754 双精度浮点存储下的真实值与 toFixed 截断逻辑

2. ECMAScript 规范的定义逻辑

ECMAScript 官方规范对 Number.prototype.toFixed(fractionDigits) 的定义算法非常明确：其数学原理是寻找一个整数 $n$，使得 $n / 10^f - x$ 最接近于 0（其中 $x$ 为原数值，$f$ 为指定的小数位数）。如果有两个这样的整数，则选取数值较大的那个。

这意味着：从规范本身来看，toFixed 原本就是设计为四舍五入的。问题不在于规范是“五成双”还是“四舍五入”，而是在执行规范算法之前，传入规范函数的入参 $x$ 就已经因为浮点数精度限制变成了 1.00499999999999989...。面对一个实际上并不等于 1.005、而是小于它的数字，算法完全依照逻辑得出了 1.00 的舍入结果。

三、常见自制修复方案的陷阱与边界测试

在发现 toFixed 不可靠后，社区中出现了许多流传甚广的自制修复技巧。但很多方法在特定边界条件下依然会崩溃，必须引起警惕。

陷阱 1：简单放大 100 倍与 Math.round 结合

常见写法为：Math.round(num * 100) / 100。这种思路寄希望于先通过乘法将小数部分移到整数位，再利用 Math.round 完成四舍五入。

function badRound(num, precision) {
  const m = Math.pow(10, precision);
  return Math.round(num * m) / m;
}

console.log(badRound(1.005, 2)); // 输出示例: 1 (预期是 1.01)

直乘运算本身同样运行在浮点数乘法体系中，它不仅无法修正既有的精度误差，甚至可能因乘法运算引入额外的精度漂移。

陷阱 2：直接叠加 Number.EPSILON

Number.EPSILON 表示 1 与大于 1 的最小浮点数之间的差值（约为 $2.220446049250313 imes 10^{-16}$）。有些代码尝试通过添加 EPSILON 来强行补足那一点点微小的损失：

function epsilonRound(num, precision) {
  const m = Math.pow(10, precision);
  return Math.round((num + Number.EPSILON) * m) / m;
}

console.log(epsilonRound(1.005, 2)); // 看起来输出了 1.01
console.log(epsilonRound(1000000.005, 2)); // 输出示例: 1000000 (依然失败！)

由于浮点数精度的分布特性，数值越大，两相邻可表示浮点数之间的间距就越大。当数值达到百万级或千万级时，Number.EPSILON 远小于该数值的最低有效位精度，直接被舍弃（精度下溢），补偿完全失效。

图 2：不同舍入方案在原理、边界案例及可靠度维度的横向对比

四、原生方案修复：科学计数法位移法

如果业务系统不希望引入体积庞大的外部高精度数学库，那么在原生 JavaScript 环境中，利用科学计数法进行指数平移是目前社区公认最优雅、且兼顾性能与准确性的做法。

1. 为什么科学计数法能规避误差？

当执行 1.005 * 100 时，底层触发的是浮点数相乘，产生 100.49999999999999。但当我们构造科学计数法字符串 "1.005e2" 并使用 Number("1.005e2") 解析时，V8 引擎内部采用十进制指数规格化解析，直接得到精确的浮点数 100.5。

此时再调用原生的 Math.round(100.5)，就能顺利触发四舍五入进位规则得到整数 101。之后再次通过反向科学计数法 "101e-2"，平移回正确的小数位 1.01。

图 3：科学计数法位移舍入函数的内部执行链路

2. 封装高可用 roundFixed 函数

为了在工程中完全替代有缺陷的 toFixed，我们需要封装一个完整的工具函数。该函数必须处理以下边界情况：

• 非数字（NaN、非有效输入）的安全校验；
• 负数的独立符号提取（避免 -0.5 在不同引擎的 Math.round 下产生方向歧义）；
• 指定小数位小于或等于 0 的整数舍入支持；
• 严格按照指定位数补足末尾的 0（保证输出格式对齐）。

/**
 * 高可用四舍五入工具函数
 * @param {number|string} val 需要格式化的数字或数字字符串
 * @param {number} precision 保留小数位数，默认 2 位
 * @returns {string} 格式化后的字符串
 */
function roundFixed(val, precision = 2) {
  const num = Number(val);
  // 边界保护：非有效数值直接抛错或返回空字符
  if (Number.isNaN(num) || !Number.isFinite(num)) {
    return '0';
  }

  // 保证 precision 为非负整数
  const digits = Math.max(0, Math.floor(precision));

  // 提取正负符号，按纯正数进行平移运算
  const isNegative = num < 0;
  const absNum = Math.abs(num);

  // 步骤 1：利用科学计数法指数右移小数点
  const shifted = Number(`${absNum}e+${digits}`);

  // 步骤 2：利用原生 Math.round 完成标准四舍五入
  const rounded = Math.round(shifted);

  // 步骤 3：利用科学计数法反向左移小数点归位
  const resultNum = Number(`${rounded}e-${digits}`);

  // 步骤 4：补齐指定小数位数的末尾 0
  const parts = resultNum.toString().split('.');
  const integerPart = parts[0];
  let decimalPart = parts[1] || '';

  if (digits > 0) {
    decimalPart = decimalPart.padEnd(digits, '0');
    return `${isNegative ? '-' : ''}${integerPart}.${decimalPart}`;
  }

  return `${isNegative ? '-' : ''}${integerPart}`;
}

五、金融与严肃计算场景：引入专用高精度库

虽然科学计数法平移方案在 95% 以上的前端页面展示、报表可视化中已经足够稳定，但在**在线结算、货币交易、计税计费**等严谨金融场景中，依然存在潜伏风险：例如超大数字（超过 Number.MAX_SAFE_INTEGER 即 $2^{53} - 1 = 9007199254740991$）或者多次运算产生的累计微差。

推荐选型：Big.js 与 Decimal.js

• big.js：体积极小（压缩后仅约 6KB），支持常见的加减乘除及多种舍入模式，适合绝大多数移动端与电商前端项目。
• decimal.js：功能最完备的高精度库，支持三角函数、开方及高级进制配置，适合复杂的金融衍生品计算。

// 使用 big.js 实现严格金融级四舍五入
// 安装: npm install big.js
import Big from 'big.js';

// Big.ROUND_HALF_UP 对应标准四舍五入 (模式值为 1)
Big.RM = Big.ROUND_HALF_UP;

function formatCurrency(val, precision = 2) {
  try {
    const b = new Big(val);
    // toFixed 会严格按照指定的 ROUND_HALF_UP 进行十进制精准四舍五入
    return b.toFixed(precision);
  } catch (err) {
    return '0.00';
  }
}

console.log(formatCurrency('1.005', 2)); // 输出示例: "1.01"
console.log(formatCurrency('1.055', 2)); // 输出示例: "1.06"
console.log(formatCurrency('-1.005', 2)); // 输出示例: "-1.01"

六、业务场景技术选型与最佳实践

在实际工程架构中，不应盲目为了追求极致精度而在所有地方引入高精度库，也不应粗心大意继续裸用 toFixed。合理的技术选型应根据业务场景对“精度要求”、“计算频次”与“包体积要求”进行权衡：

图 4：业务场景舍入方案与架构分工决策树

七、总结

JavaScript 的 toFixed() 表现出的“不准确”，并不是随机的语法错误，而是现代计算机底层采用二进制 IEEE 754 浮点数表示十进制小数时的内在妥协。由于 1.005 在内存中实际存储为 1.00499999999999989...，算法按照逻辑对第 3 位（4）向下舍去，导致看似未按“四舍五入”进位。

解决该问题的核心在于避免直接的浮点运算干扰：在前端轻量通用场景下，采用科学计数法指数位移并补零的封装函数 roundFixed()，即可用极小的体积成本解决绝大多数展示偏差；而在严谨的金融与交易场景下，则应通过后端直接返回预格式化结果，或在前端引入 Big.js 这类成熟十进制高精度库进行计算，确保每一分钱都精确无误。