怎么解决JavaScript浮点数精度导致的取整错误

图 0：JavaScript 浮点数运算取整失真排查与精准修复概览

一、问题复现：取整错误的具体表现与根本成因

在日常业务开发中，开发者常常需要将带小数的数值转换为整数或保留指定位小数。例如在电商或计费场景中，将“元”换算为“分”：

// 场景 1：向下取整丢失整整 1 分钱
const price = 1.14;
const fenFloor = Math.floor(price * 100);
console.log(fenFloor); // 输出：113 ❌（预期应为 114）

// 场景 2：直接截断产生相同偏差
const fenTrunc = Math.trunc(price * 100);
console.log(fenTrunc); // 输出：113 ❌

// 场景 3：四舍五入未进位
const weight = 1.005;
const rounded = Math.round(weight * 100) / 100;
console.log(rounded);  // 输出：1 ❌（预期应为 1.01）

为什么会出现这样偏离直觉的错误？根源在于计算机底层的数字存储格式：

• IEEE 754 双精度表示限制：JavaScript 所有数字统一为 64 位双精度浮点数，由 1 位符号位、11 位指数位以及 52 位有效尾数（Mantissa）构成。
• 十进制与二进制的无限循环转换：十进制的 0.14 在二进制展开中是无限循环小数 0.001000111101011100...₂。由于只有 52 位尾数空间，超出部分被迫执行截断与就近舍入，导致存入内存的值本身就存在大约 10⁻¹⁷ 级别的微小残差。
• 乘法放大与不连续截断：当执行 1.14 * 100 时，该微小残差随之放大，实际运算结果在 CPU 寄存器中为 113.999999999999985789...。虽然与 114 相比只差了约 1.42 × 10⁻¹⁴，但 Math.floor() 和 Math.trunc() 是离散阶梯函数，只要小数部分没有达到临界整数，其整型截断机制便会无情将其打回 113，从而造成整整 1 个最小计数单位的硬性丢失。

图 1：浮点数运算与取整截断误差产生机理（从尾数截断到离散跃迁）

二、解决方案一：科学记数法指数位移法（前端首选推荐）

解决该类取整错误最稳健且无外部依赖的方法是指数记数位移法。传统的做法是通过 num * 100 移动小数点，这会触发浮点乘法引擎；而指数位移法利用 JavaScript 原生的科学记数法（如 1.14e+2）在字符语法解析层面移动小数点，随后进行整型取整，再通过负指数（e-2）还原小数位。

ECMAScript 规范在解析科学记数法字符串转换为数字时，会对十进制有效位进行精准平移，不会引入中间乘法的微弱下溢。以下是经过完整边界处理的通用安全取整函数：

/**
 * 基于指数记数法的安全向下取整
 * @param {number|string} value 待取整数值
 * @param {number} decimals 保留小数位数（默认为 0，即取整到个位）
 * @returns {number} 取整后的准确数值
 */
function safeFloor(value, decimals = 0) {
  const num = Number(value);
  if (Number.isNaN(num) || !Number.isFinite(num)) return num;

  // 步骤 1：拆分现有科学记数法指数（防止传入形如 1.2e-5 的数值发生格式错误）
  const parts = num.toString().split('e');
  const curExp = parts[1] ? Number(parts[1]) : 0;

  // 步骤 2：正向位移小数点并执行 Math.floor
  const shifted = Math.floor(Number(parts[0] + 'e' + (curExp + decimals)));

  // 步骤 3：反向位移还原目标小数位数
  const shiftedParts = shifted.toString().split('e');
  const backExp = shiftedParts[1] ? Number(shiftedParts[1]) : 0;
  return Number(shiftedParts[0] + 'e' + (backExp - decimals));
}

/**
 * 基于指数记数法的安全四舍五入
 */
function safeRound(value, decimals = 0) {
  const num = Number(value);
  if (Number.isNaN(num) || !Number.isFinite(num)) return num;

  const parts = num.toString().split('e');
  const curExp = parts[1] ? Number(parts[1]) : 0;
  const shifted = Math.round(Number(parts[0] + 'e' + (curExp + decimals)));

  const shiftedParts = shifted.toString().split('e');
  const backExp = shiftedParts[1] ? Number(shiftedParts[1]) : 0;
  return Number(shiftedParts[0] + 'e' + (backExp - decimals));
}

// 运行验证：
console.log(safeFloor(1.14, 2));  // 输出：1.14
console.log(Math.floor(Number("1.14e+2"))); // 输出：114 ✅
console.log(safeRound(1.005, 2)); // 输出：1.01 ✅

图 2：指数记数法安全取整执行步骤（以 safeFloor(1.14, 2) 为例）

三、解决方案二：Number.EPSILON 极小偏置补偿法

在 ES6 中引入了标准常量 Number.EPSILON，其值为 2⁻⁵² ≈ 2.220446049250313 × 10⁻¹⁶。它代表数字 1 与大于 1 的最小浮点数之间的差值，即 JavaScript 浮点数所能辨别的最小单位微差。

当执行 1.005 * 100 得到 100.49999999999999 时，只需给这个由于下溢而略微不足的值加上一个微小的偏移量，就能将其轻推过临界中点，使四舍五入得到正确的结果：

// 带有 EPSILON 偏置的四舍五入
function roundWithEpsilon(val, decimals = 0) {
  const factor = Math.pow(10, decimals);
  return Math.round((val + Number.EPSILON) * factor) / factor;
}

// 带有 EPSILON 偏置的向下取整
function floorWithEpsilon(val, decimals = 0) {
  const factor = Math.pow(10, decimals);
  return Math.floor((val * factor) + Number.EPSILON) / factor;
}

console.log(roundWithEpsilon(1.005, 2)); // 输出：1.01 ✅
console.log(floorWithEpsilon(1.14, 0));  // 输出：114 ✅

四、解决方案三：业务层面“最小整数单位”方案（分制化）

在支付、结算以及商品标价等敏感业务中，解决浮点数精度问题的业界黄金法则是：完全杜绝在运算层使用小数。所有金额在进入数据存储和业务计算前，统一转化为“分”（甚至“厘”）为单位的纯整数存储与运算。

关键点在于：当用户在表单输入框中输入 "1.14" 时，切勿直接调用 parseFloat(str) * 100，因为这一步就已经踏入了浮点乘法陷阱。正确做法是通过字符串解析安全拆分并补齐角分：

/**
 * 将元字符串安全解析为整数“分”，彻底绕过浮点运算
 * @param {string|number} yuanInput 例如 "1.14"、"0.8"、"15"
 * @returns {number} 纯整数“分”
 */
function yuanToFenSafe(yuanInput) {
  const str = String(yuanInput).trim();
  if (!/^-?\d+(\.\d+)?$/.test(str)) {
    throw new TypeError("非法金额格式: " + yuanInput);
  }

  const isNegative = str.startsWith('-');
  const cleanStr = isNegative ? str.slice(1) : str;
  const [yuanPart, fenPart = ''] = cleanStr.split('.');

  // 提取前两位小数并自动补零（如 "8" -> "80", "" -> "00"）
  const paddedFen = (fenPart + '00').slice(0, 2);
  const totalFen = Number(yuanPart) * 100 + Number(paddedFen);

  return isNegative ? -totalFen : totalFen;
}

console.log(yuanToFenSafe("1.14")); // 准确输出纯整数：114 ✅
console.log(yuanToFenSafe("0.29")); // 准确输出纯整数：29 ✅

只要数据流全程保持整数“分”，后续的满减计算、批量汇总或向下取整就可以直接安全使用原生的 Math.floor()，因为整数在 JavaScript 允许的安全整数范围内（Number.MIN_SAFE_INTEGER 至 Number.MAX_SAFE_INTEGER，即 ±9007199254740991）不存在任何精度损失。

五、解决方案四：引入成熟高精度数学库（金融财务标准）

如果项目中涉及外汇汇率、复杂利息计算、多项折扣分摊等长链条公式运算，任何纯前端手写代码都会面临无穷无尽的边缘情况。此时应当引入经过严格测试的高精度计算库，如 decimal.js、bignumber.js 或轻量级的 big.js。

// 以成熟的 decimal.js 为例（支持 npm install decimal.js）
import Decimal from 'decimal.js';

// 设置四舍五入模式或向下取整模式
const price = new Decimal('1.14');
const fen = price.times(100).floor();

console.log(fen.toNumber()); // 输出：114 ✅（无任何精度闪烁）

// 复杂除法向下截断保留两位小数
const result = new Decimal('10')
  .dividedBy('3')
  .toDecimalPlaces(2, Decimal.ROUND_DOWN);

console.log(result.toString()); // 输出："3.33" ✅

此类类库在底层将数字拆解为符号、基数数组与指数，在软件层完全模拟十进制运算法则，彻底免疫所有硬件层二进制浮点截断。

图 3：JavaScript 浮点数取整与舍入方案选型指南决策树

六、方案综合对比与选型决策

在实际工程中，并非所有项目都需要引入 30KB 的数学库，也不应盲目全部依赖手写补丁。请根据业务严格程度与运行环境选择匹配的方案：

图 4：四种常见浮点数取整方案综合对比矩阵

七、生产环境避坑指南

在解决浮点数取整问题时，还要避免以下常见的二次开发陷阱：

1. 警惕位运算取整（| 0 与 ~~）

很多 JavaScript 开发者习惯用 x | 0 或 ~~x 代替 Math.trunc() 进行整数截断。虽然位运算在纯整数场景性能优秀，但在浮点数精度问题上不但毫无帮助，还会引入更危险的问题：

• 对 (1.14 * 100) | 0，依然会直接截断为 113。
• JavaScript 位运算符会将操作数强制转换为 32 位有符号整数。如果数值超过 2³¹ - 1（约 21.47 亿），位运算会直接发生整数溢出并产生负数！例如 3000000000 | 0 会变成 -1294967296。

2. 不要误把 toFixed() 当作数学四舍五入

原生 Number.prototype.toFixed() 返回的是格式化字符串，并且其底层实现是基于“银行家舍入法”（四舍六入五成双）的近似规则，同时仍然受 IEEE 754 精度误差影响。例如在主流现代浏览器中：

console.log((1.005).toFixed(2)); // 在 Chrome/Node.js 中返回 "1.00" ❌ 而不是 "1.01"
console.log((35.855).toFixed(2)); // 返回 "35.85" ❌

如果业务逻辑依赖数学上的四舍五入（即半数向上取整），绝不能直接使用 toFixed()，而应统一调用前述的 safeRound() 函数。

3. 严格遵循“计算逻辑与展示格式分离”原则

在数据处理链路上，计算阶段应始终保持原始高精度数字或整数分制状态进行传递，切勿在每一步都过早进行字符串化与舍入；仅在最后一步将结果呈现给用户界面时，才调用取整或格式化函数。这样可以有效防止局部舍入误差在计算链条中逐级放大。