JS浮点数精度导致取整错误怎么办？

一、故障现场：那些令人意外的取整错误

在日常开发中，前端开发者经常需要处理货币单位换算（如将“元”转换为“分”）、坐标网格对齐、进度百分比计算等场景。直觉上，乘以 100 之后再取整是非常自然的操作，但实际运行结果却频繁突破直觉：

// 现场一：乘 100 后向下取整，直接少 1 分钱
console.log(1.14 * 100);             // 输出：113.99999999999999
console.log(Math.floor(1.14 * 100)); // 输出：113（期望是 114！）
console.log(Math.floor(0.29 * 100)); // 输出：28 （期望是 29！）

// 现场二：四舍五入发生“反向跳水”
console.log(1.005 * 100);                    // 输出：100.49999999999999
console.log(Math.round(1.005 * 100) / 100);  // 输出：1（期望保留两位是 1.01！）

// 现场三：使用位运算截断小数时的连环陷阱
console.log(~~(1.14 * 100));         // 输出：113（位运算与 Math.trunc 一样遵循向零截断）
console.log(~~(3000000000.5));       // 输出：-1294967296（位运算强制32位有符号整型，直接溢出成负数！）

这些现象往往不是每次都出现，而是偶发于特定的数字输入中。由于难以在简单的单元测试中全量穷举，极易遗漏到生产环境中，最终在财务对账、优惠券满减计算或用户积分结算时引发真实客诉。

二、根因剖析：为什么取整会“凭空少 1”？

要彻底解决取整错误，必须理解计算机底层如何表示这些小数。JavaScript 中的所有数字均采用 IEEE 754 标准的 64 位双精度浮点数（Double Precision）存储。这 64 个二进制位被划分为三部分：1 位符号位（Sign）、11 位指数位（Exponent）和 52 位尾数位（Mantissa）。

人类习惯使用的十进制小数与计算机底层的二进制小数之间存在天然的换算隔阂。在十进制下，只有分母的质因数仅包含 2 和 5 的分数（例如 1/2=0.5、1/4=0.25）才能在有限位数内表示；而像 1.14 中的 0.14，换算成二进制时会变成无限循环小数：

0.14 (十进制) = 0.00100011110101110000101000111101011100001... (二进制无限循环)

然而，硬件给尾数分配的空间只有 52 位。超出第 52 位的二进制数字只能被强制舍入截断。因此，计算机在内存中实际保存的 1.14，真值其实是：

1.13999999999999990230037376...

当执行 1.14 * 100 时，浮点乘法器将这个微小的欠缺值放大了 100 倍，计算寄存器中的内部结果精确落在了 113.99999999999999。此时如果调用 Math.floor() 或 Math.trunc()，取整算法只认数值的数学绝对大小。既然当前数值是 113 点几，哪怕只差 0.00000000000001 才到 114，算法依然会毫不犹豫地将整个小数部分砍去，最终残忍地输出 113。

三、诊断与排查步骤

当项目中出现可疑的数值偏差时，切忌盲目添加 + 1 或随手调整四舍五入。建议按照以下四步标准流程进行诊断与处理：

第 1 步：现场捕获与真值探查

许多开发者在调试时使用 console.log(val)，发现输出的经常是看似正常的整数或规范小数。这是因为 JavaScript 引擎的 Number.prototype.toString() 在默认输出时会进行一定程度的四舍五入优化，从而掩盖了底层的残差。

排查时必须使用 toPrecision(16) 或 toFixed(20) 打印完整有效位数，才能准确抓获隐藏在浮点数末端的 .99999999999999 或 .00000000000001：

let total = 1.14 * 100;
console.log(total);                  // 可能显示：113.99999999999999
console.log(total.toPrecision(16));  // 真实有效精度：113.9999999999999
console.log(total.toFixed(20));      // 113.99999999999998578915

第 2 步：业务场景定级

明确当前计算所在的业务层级与精度容忍度：

• 交易结算 / 资产对账（零容忍）：严禁纯前端进行浮点乘除与取整，必须遵循前后端契约，统一以“分”或“厘”整型传递，或使用高精度库。
• 通用业务 UI 展示（高容忍）：需要显示保留两位小数的百分比、汇率或金额时，采用科学计数法指数移位算法。
• 高性能动效 / 像素对齐（高吞吐）：关注执行性能而非微米级精度，可采用轻量容差补偿。

第 3 步：针对性修复实现

根据定级结果，在公共模块中引入对应方案，禁止在业务组件内散落手写临时逻辑。

第 4 步：边界用例断言

修复完成后，必须编写单元测试覆盖以下经典恶劣边界：

• 乘倍数后向下取整：1.14 * 100、0.29 * 100、1.4 * 100；
• 临界点四舍五入：1.005、0.105、1.355 保留两位小数；
• 极小值科学计数法转字符串：0.0000005；
• 超出安全整数边界：超过 Number.MAX_SAFE_INTEGER (9007199254740991)。

四、四种工程化解决方案与代码实现

方案一：Epsilon 容差补偿法（轻量级截断修复）

ES6 引入了 Number.EPSILON，它表示 1 与大于 1 的最小浮点数之间的差值（约为 2.220446049250313e-16），代表了 64 位双精度浮点数在数值 1 附近的机器最小精度极限。

当由于浮点乘法导致数值比预期目标微小欠缺了 1e-14 ~ 1e-16 时，在进行向下取整前人为注入一个微小的容差偏移量，就能将处于坍塌边缘的 113.99999999999999 安全托举回 114，而对于正常的真正小数（如 113.8）则完全不会发生越级进位：

/**
 * 安全向下取整（解决乘倍数后 floor 丢失 1 的问题）
 * @param {number} value - 需要取整的数值（或运算表达式）
 * @param {number} [epsilon=Number.EPSILON] - 容差阈值
 * @returns {number} 取整后的整数
 */
function safeFloor(value, epsilon = Number.EPSILON) {
  // 加上机器精度阈值，弥补 0.99999999999999 的微小缺口
  return Math.floor(value + epsilon);
}

// 运行验证：
console.log(safeFloor(1.14 * 100)); // 输出：114 (修复成功！)
console.log(safeFloor(0.29 * 100)); // 输出：29  (修复成功！)
console.log(safeFloor(1.4 * 100));  // 输出：140 (修复成功！)
console.log(safeFloor(113.8));      // 输出：113 (正常小数不发生错误进位)

方案二：科学计数法指数移位法（标准化四舍五入）

在处理 Math.round() 或保留 N 位小数时，直接 Math.round(val * 100) / 100 经常遭遇 1.005 变成 1 的问题。MDN 官方推荐的解决范式是：使用科学计数法的字符串平移，绕过浮点乘法的尾数扰动。

/**
 * 高精度四舍五入保留指定小数位（规避 1.005 舍入跳水）
 * @param {number|string} value - 原始数值
 * @param {number} [decimals=0] - 保留小数位数
 * @returns {number} 纠偏后的数值
 */
function safeRound(value, decimals = 0) {
  if (!isFinite(value)) return Number(value);
  
  // 第一步：将小数点右移 decimals 位（利用指数 'e+' 避免乘法二进制失真）
  const parts = String(value).split('e');
  const exp = parts[1] ? Number(parts[1]) + decimals : decimals;
  const shifted = Math.round(Number(parts[0] + 'e' + exp));

  // 第二步：将小数点重新左移 decimals 位复原
  const backParts = String(shifted).split('e');
  const backExp = backParts[1] ? Number(backParts[1]) - decimals : -decimals;
  return Number(backParts[0] + 'e' + backExp);
}

// 运行验证：
console.log(safeRound(1.005, 2)); // 输出：1.01 (正确进位！)
console.log(safeRound(0.105, 2)); // 输出：0.11 (正确进位！)
console.log(safeRound(1.14 * 100, 0)); // 输出：114 (安全取整)

方案三：业务源头“整型化”治理（金额转分最佳实践）

在所有精度故障中，金额计算引发的经济损失最为致命。最彻底的工程治理方案并非在客户端研究高难度算法，而是在系统架构层面达成共识：将金额的最小单位下沉为整型“分”或“厘”。

若前端接收到的必须是用户输入的金额字符串（如 "1.14"），应直接通过字符串解析拼接为整型分，从物理上切断浮点乘法介入的可能：

/**
 * 将元格式字符串安全转换为以分表示的整型（不经过浮点乘法）
 * @param {string|number} yuanStr - 例如 "1.14" 或 1.14
 * @returns {number} 整型分，例如 114
 */
function yuanToCent(yuanStr) {
  const str = String(yuanStr).trim();
  if (!/^-?\d+(\.\d+)?$/.test(str)) {
    throw new Error('非法数值格式');
  }

  const [integerPart, decimalPart = ''] = str.split('.');
  // 截取或补齐两位小数
  const paddedDecimal = (decimalPart + '00').slice(0, 2);
  
  const isNegative = str.startsWith('-');
  const absInteger = integerPart.replace('-', '');
  
  const centValue = Number(absInteger + paddedDecimal);
  return isNegative ? -centValue : centValue;
}

// 运行验证：
console.log(yuanToCent("1.14"));   // 输出：114 (100% 稳定可靠)
console.log(yuanToCent("0.29"));   // 输出：29  (绝不会出现 28)
console.log(yuanToCent("12.5"));   // 输出：1250
console.log(yuanToCent("100"));    // 输出：10000

方案四：引入成熟高精度数学库

如果业务场景涉及电商购物车满减均摊、年化收益率复利计算、多步骤税率折算等连续长链路计算，零依赖的手写函数将面临极大的维护成本。此时应当直接引入业内成熟的高精度数学库（如 big.js 或 decimal.js）：

// 使用 big.js (体积仅约 6KB)
import Big from 'big.js';

// 解决 1.14 * 100 取整问题
const totalCent = new Big(1.14).times(100).round(0, Big.roundDown).toNumber();
console.log(totalCent); // 输出：114

// 连续精确计算
const result = new Big(0.1).plus(0.2).times(10).round(2).toNumber();
console.log(result); // 输出：3

五、方案选型与适用场景对比

没有任何一种方案能够在包体积、运行速度、运算精度和使用简易度上同时达到完美。在选型时，建议根据业务场景进行权衡决策：

六、高频避坑指南与边界防御

console.log(parseInt(0.0000005)); // 输出：5！
// 原因：0.0000005.toString() 结果为 "5e-7"
// parseInt("5e-7") 解析到字符 'e' 停止，只保留开头的 5！

七、总结与速查清单

JavaScript 浮点数取整错误不是语法缺陷，而是计算机体系结构在有限存储空间下表达实数的必然代价。构建健壮的数值防御体系，核心在于不把责任寄托于开发者的个人经验，而是依赖团队的规范与工具沉淀。

日常开发落地速查要点：

1. 看见乘法乘 100 就警惕：代码审查（Code Review）中，凡是出现 Math.floor(x * 100)、Math.round(x * 100) 均视为潜在缺陷；
2. 取整封装收口：项目内统一引入 safeFloor 与 safeRound 工具函数，禁止直接裸写取整函数处理浮点算式；
3. 金额入参即定标：与后端接口交互金额时，要求服务端返回整型“分”，前端仅在最终绘制视图的瞬间除以 100 展示；
4. 警惕类型隐式转换：禁止使用 parseInt 截取小数，杜绝使用 ~~、| 0 处理超过 32 位可能的数值；
5. 测试用例常态化：在项目的单元测试套件中固化 1.14、0.29、1.005 等测试基线，确保构建流水线持续拦截精度回归。