JavaScript浮点数求余精度丢失怎么办

一、问题复现：看似简单的求余为何频频翻车

在前端业务开发中，浮点数求余的出现频率远比想象中高。设想一个电商购物车阶梯满减场景：每满 0.2 万元立减优惠，当前用户加购金额为 5.6 万元，前端试图通过求余判断是否刚好达到整倍数门槛：

const total = 5.6;
const step = 0.2;

console.log(total % step === 0); // 输出 false！
console.log(total % step);        // 输出 0.1999999999999993

同样的问题在更小的小数求余中依然稳定复现：

console.log(0.3 % 0.1);   // 预期 0，实际输出 0.09999999999999998
console.log(1.15 % 0.05); // 预期 0，实际输出 0.04999999999999996
console.log(2.3 % 0.7);   // 预期 0.2，实际输出 0.19999999999999996

这种误差不仅导致等值判断（=== 0）失效，还会让基于余数计算步长吸附、UI 滑块对齐或分页分块的逻辑出现 1 像素或一个微小单位的漂移抖动。

二、根本原因：IEEE 754 截断商与二进制精度陷阱

JavaScript 所有的数字（除 BigInt 外）均遵循 IEEE 754 标准，采用 64 位双精度浮点数表示。在计算机底层，绝大多数十进制小数（例如 0.1、0.2、0.3）在转换为二进制时都是无限循环小数，只能保留 53 位有效数字（包含隐含位），必须进行尾数截断。

根据 ECMAScript 规范，求余运算符 a % b 的计算公式严格定义为：

r = a - (b * Math.trunc(a / b))

当执行 0.3 % 0.1 时，内部实际发生了以下计算链：

• 十进制 0.3 在 64 位二进制存储为 0.2999999999999999888977697...（略小于 0.3）；
• 十进制 0.1 在 64 位二进制存储为 0.1000000000000000055511151...（略大于 0.1）；
• 执行浮点除法 0.3 / 0.1 时，由于分子偏小且分母偏大，商的计算结果为 2.9999999999999996；
• Math.trunc(2.9999999999999996) 执行向零截断，商直接变成了 2，而不是数学上的 3；
• 代入余数公式：0.3 - 2 * 0.1 = 0.09999999999999998。

由此可见，浮点求余的精度丢失并不仅仅是末位几位的小数漂移，而是商数被向下截断少算了一整倍除数，导致得出了一个极其接近除数的“巨大虚假余数”。

三、核心解决方案：动态整数缩放法

针对这一痛点，工程中最轻量、性能最高且零依赖的解决手段是将运算提升至整数域执行，运算完成后再降阶还原。

1. 四步处理流程

1. 提取最大小数位：将除数与被除数转换为字符串，分别解析两者小数点后的位数，取其最大值 maxDecimals；
2. 安全整数放大：计算放大倍率 factor = 10 ** maxDecimals。必须使用 Math.round 消除乘法本身引入的次级浮点微小抖动（如 1.15 * 100 = 114.99999999999999）；
3. 原生整数取模：在 JavaScript 的安全整数范围（Number.MAX_SAFE_INTEGER 即 9007199254740991）内，原生 % 对整数的运算结果具备绝对数学精度；
4. 降阶还原浮点数：将整数求模结果除以 factor，获得精确的十进制浮点余数。

2. 工业级可复用函数实现

下面是考虑了科学计数法解析、除零防御及符号保持的完整生产级封装：

/**
 * 安全浮点数求余运算函数
 * @param {number} dividend 被除数
 * @param {number} divisor 除数
 * @returns {number} 精确求余结果
 */
function safeMod(dividend, divisor) {
  // 1. 特殊与非有效输入防护
  if (divisor === 0) return NaN;
  if (!Number.isFinite(dividend) || !Number.isFinite(divisor)) return NaN;
  if (dividend === 0) return 0;

  // 2. 安全获取数值的小数位数（兼容科学计数法）
  const getDecimalLength = (num) => {
    const str = String(num);
    // 处理科学计数法形如 1.2e-4
    if (str.includes('e-')) {
      const [base, exp] = str.split('e-');
      const baseDecimals = (base.split('.')[1] || '').length;
      return baseDecimals + parseInt(exp, 10);
    }
    const dotIndex = str.indexOf('.');
    return dotIndex === -1 ? 0 : str.length - dotIndex - 1;
  };

  const lenA = getDecimalLength(dividend);
  const lenB = getDecimalLength(divisor);
  const maxDecimals = Math.max(lenA, lenB);

  // 3. 安全整数防溢出校验（JS安全整数约为15~17位）
  if (maxDecimals > 15) {
    console.warn('safeMod: 小数位过多，建议使用 Decimal.js 避免安全整数溢出');
  }

  // 4. 缩放、舍入消除初次浮点微差、求模与还原
  const factor = 10 ** maxDecimals;
  const intDividend = Math.round(dividend * factor);
  const intDivisor = Math.round(divisor * factor);

  // 5. 整数求模并降阶还原
  return (intDividend % intDivisor) / factor;
}

3. 运行验证

console.log(safeMod(0.3, 0.1));   // 输出: 0 （彻底消除 0.099999...）
console.log(safeMod(5.6, 0.2));   // 输出: 0
console.log(safeMod(1.15, 0.05)); // 输出: 0
console.log(safeMod(2.3, 0.7));   // 输出: 0.2
console.log(safeMod(-5.6, 0.2));  // 输出: 0 （保持与原生的负被除数符号约定）
console.log(safeMod(-2.3, 0.7));  // 输出: -0.2

四、方案对比与选型维度

除了动态整数缩放法，前端社区中还常见“四舍五入校准法”以及引入“第三方高精度数学库”。不同方案在打包体积、执行性能和数值边界上各有侧重。

方案	打包体积	计算性能	适用上限	典型业务场景
动态整数缩放 (safeMod)	0 KB（纯原生代码）	极高（接近原生指令）	有效数字 ≤ 15 位	前端滑块步长吸附、图表标尺、普通业务计算
商数四舍五入校准	0 KB（单行表达式）	极高	仅适用于整除判定	仅校验 a 是否能被 b 整除的轻量校验
高精度库 (decimal.js)	约 12~30 KB	较慢（纯软件大数模拟）	无上限（支持任意指定精度）	电商订单满减、金融理财分期、数字货币交易

方案二补充：仅判定是否整除时的极简单行流

若业务逻辑仅仅想判断“a 是否能被 b 整除”，而不需要通用的非零余数，可直接借助商数的四舍五入逼近：

// 判断 a 是否是 b 的整数倍（容差阈值法）
function isDivisible(a, b, epsilon = 1e-10) {
  const quotient = a / b;
  return Math.abs(quotient - Math.round(quotient)) < epsilon;
}

console.log(isDivisible(0.3, 0.1)); // true
console.log(isDivisible(5.6, 0.2)); // true

方案三补充：金融场景下 decimal.js 的标准写法

若涉及核心账目分摊与利息折算，推荐直接使用经过严格测试的成熟库：

// 需要在项目中安装: npm install decimal.js
import Decimal from 'decimal.js';

const a = new Decimal(0.3);
const b = new Decimal(0.1);
const result = a.mod(b).toNumber();

console.log(result); // 精确输出: 0

五、总结与避坑检查表