JavaScript 金额计算精度丢失与分摊方案

一个负数的补贴金额，足以让整个业务逻辑崩溃。

二、根源探寻：IEEE 754 标准下的'先天缺陷'

要解决问题，必先理解其根源。JavaScript 中的所有数字（包括整数）都以 64 位双精度浮点数（IEEE 754 标准） 的形式存储。这个标准的设计初衷是为了在有限的内存空间内表示极大范围的数值，但它牺牲了精度。

为什么 0.1 无法被精确表示？

计算机内部使用二进制。就像我们无法在十进制中精确表示 1/3（它等于 0.3333... 无限循环）一样，很多十进制小数也无法在二进制中被精确表示。

0.1 的二进制转换过程：

1. 0.1 * 2 = 0.2 → 取整数部分 0
2. 0.2 * 2 = 0.4 → 取整数部分 0
3. 0.4 * 2 = 0.8 → 取整数部分 0
4. 0.8 * 2 = 1.6 → 取整数部分 1
5. 0.6 * 2 = 1.2 → 取整数部分 1
6. 0.2 * 2 = 0.4 → …开始循环

所以，0.1 的二进制表示是 0.0001100110011001100...，这是一个无限循环小数。

当两个这样的近似值相加时，误差会累积，最终导致 0.1 + 0.2 不再精确等于 0.3。

三、错误方案：为什么 toFixed 和 Math.round 治标不治本？

很多开发者会尝试使用 Number.prototype.toFixed() 或 Math.round() 来解决问题。

(0.1 + 0.2).toFixed(2); // "0.30"
(0.1 + 0.2).toFixed(2) === "0.30"; // true

toFixed 确实可以格式化输出，但它返回的是字符串，且其内部计算依然基于浮点数。更重要的是，在分摊场景中，对每一项分别进行四舍五入，会导致舍入误差的累积。

流程推演：

1. 开始分摊
2. 计算第一项份额 -> Math.round -> 引入误差 1
3. 计算第二项份额 -> Math.round -> 引入误差 2
4. ...
5. 计算最后一项份额 -> 总额 - 已分配金额 -> 误差累积放大
6. 结果：负数或总和不对 -> 业务异常!

结论： 这些方法只能用于最终结果的展示，绝不能用于中间过程的计算。

四、核心策略：整数运算——以'分'为单位治本

金融和电商领域的标准实践是：永远不要用浮点数进行金额计算。

核心思想：将所有金额乘以 100，转换为最小的货币单位（如'分'），然后全程使用整数进行运算，最后再将结果除以 100 转回'元'。 整数在 JavaScript 中是安全的（只要不超过 Number.MAX_SAFE_INTEGER），可以保证加减乘除的精确性。

算法详解：整数分摊法

为了保证分摊后的总和严格等于原始总额，并避免出现负数，我们采用 '向下取整 + 最后一项兜底' 的策略。

1. 转为整数：将所有金额（元）转换为'分'。
2. 保守分配：遍历列表，对非最后一项，按比例计算其份额，并使用 Math.floor()向下取整。这确保了每一项分配的金额都不会'超支'。
3. 累加已分配：记录已经分配出去的总金额。
4. 最后一项兜底：最后一项的份额 = 总金额 - 已分配金额。这个操作可以吸收前面所有 Math.floor() 造成的舍去误差，确保总和精确。

五、代码实现：生产级 TypeScript 方案

下面是一个健壮的、带有完整类型注解和注释的 TypeScript 实现。

/**
 * 将金额按比例精确分摊到多个项目上，确保总和严格等于原始金额。
 *
 * @param totalAmountCents 需要分摊的总金额（单位：分，整数）
 * @param itemAmountsInYuan 各个项目的基准金额数组（单位：元，用于计算比例）
 * @returns 分摊后的金额数组（单位：元，保留两位小数）
 */
export function distributeAmountPrecisely(
  totalAmountCents: number,
  itemAmountsInYuan: number[]
): number[] {
  // --- 1. 防御性校验 ---
  if (totalAmountCents <= 0 || itemAmountsInYuan.length === 0) {
    return new Array(itemAmountsInYuan.length).fill(0);
  }

  // --- 2. 转换为整数（分）---
  const itemAmountsInCents = itemAmountsInYuan.map(amount => Math.round(amount * 100));
  const totalItemAmountInCents = itemAmountsInCents.reduce((sum, cents) => sum + cents, 0);

  if (totalItemAmountInCents === 0) {
    return new Array(itemAmountsInYuan.length).fill(0);
  }

  // --- 3. 核心分摊逻辑 ---
  let allocatedCents = 0;
  const distributedAmountsInYuan: number[] = [];

  itemAmountsInCents.forEach((itemCents, index) => {
    let shareCents = 0;
    if (index === itemAmountsInCents.length - 1) {
      // 最后一项：兜底所有剩余金额，吸收所有舍入误差
      shareCents = totalAmountCents - allocatedCents;
    } else {
      // 非最后一项：按比例计算份额并向下取整，保证不超分
      // 注意：这里的乘法是整数乘法，精确无误
      shareCents = Math.floor((totalAmountCents * itemCents) / totalItemAmountInCents);
      allocatedCents += shareCents;
    }
    // 将结果从分转回元，并保留两位小数
    distributedAmountsInYuan.push(shareCents / 100);
  });

  return distributedAmountsInYuan;
}

// --- 使用示例 ---
const totalSubsidy = 30; // 30 元补贴
const goodsAmounts = [33.33, 33.33, 33.34]; // 商品金额
const shares = distributeAmountPrecisely(totalSubsidy * 100, goodsAmounts);
console.log(shares); // 输出：[10, 10, 10]
console.log(shares.reduce((s, a) => s + a, 0).toFixed(2)); // 输出："30.00"

const goodsAmounts2 = [33.30, 33.30, 33.40];
const shares2 = distributeAmountPrecisely(totalSubsidy * 100, goodsAmounts2);
console.log(shares2); // 输出：[9.99, 9.99, 10.02]
console.log(shares2.reduce((s, a) => s + a, 0).toFixed(2)); // 输出："30.00"

六、扩展与思考

1. 超大金额处理：JavaScript 的 Number.MAX_SAFE_INTEGER (即 2^53 - 1) 约等于 9 quadrillion。如果业务涉及超过此数值的金额（以分为单位），应考虑使用 BigInt。
2. 第三方库的选择：对于极其复杂的财务计算（如复利、税率），可以考虑使用专门的库，如 decimal.js, big.js。它们实现了任意精度的十进制运算，但会带来额外的性能开销和包体积。对于绝大多数前端分摊场景，整数法是性能和简洁性的最佳平衡。
3. 显示与计算分离：始终记住，计算用整数，显示用格式化。在模板中，使用 price.toFixed(2) 或过滤器来保证显示两位小数，但底层的数据模型应始终以分为单位存储或计算。

七、总结

最终建议：在处理前端金额分摊时，请将'整数分摊法'作为你的首选和标准实践。 它不仅解决了问题，更体现了一种严谨、可靠的工程思维。通过拥抱整数，我们可以从根本上规避 JavaScript 浮点数带来的陷阱，构建出经得起考验的财务应用。