JavaScript货币金额安全运算：如何规避浮点数精度误差？

嘿，这个问题简直戳中了货币金额处理的核心痛点——浮点数的精度误差真的能把人折腾疯！先给你把问题拆透，再给你一套靠谱的解决方案。

为什么会出现 1.1 * 100 = 110.00000000000001？ #

这本质是二进制浮点数的天生缺陷：它无法精确表示所有十进制小数。比如十进制的0.1，在二进制里是无限循环的小数（就像十进制里的1/3=0.333...）。当你把1.1（也就是1 + 0.1）转成二进制浮点数存储时，已经存在微小的精度损失，乘以100后这个损失被放大，就出现了看似诡异的结果。

全程用 (1.1 * 100).toFixed() 安全吗？ #

答案是不安全。toFixed()的问题在于它依赖于浮点数当前的精度状态，而浮点数本身可能已经因为存储或运算产生了误差：

• 比如1.105这个数，实际存储为浮点数时是1.1049999999999999...，此时(1.105 * 100).toFixed(0)会返回"110"，但精确的分单位应该是111（如果是真正的1.105元）。
• 它的四舍五入逻辑也可能不符合货币处理的专业要求（比如部分场景需要银行家舍入法）。

确保运算安全的核心方案：全程用整数（分单位）处理 #

既然你后端已经用int64存储数值，那最佳实践就是把所有金额都转成“分”的整数来存储、运算，彻底规避浮点数。具体操作如下：

1. 前端输入/转换时，从字符串解析整数，绕开浮点数 #

别用浮点数接收用户输入或接口返回的金额，直接用字符串处理：

// 示例：把金额字符串转成分的整数
function toCents(amountStr) {
  const [integerPart, decimalPart = "0"] = amountStr.split(".");
  // 小数部分补零到两位，仅取前两位（避免用户输入超过两位的小数）
  const paddedDecimal = decimalPart.padEnd(2, "0").slice(0, 2);
  return parseInt(integerPart) * 100 + parseInt(paddedDecimal);
}

// 测试
toCents("1.1"); // 110
toCents("0.21"); // 21
toCents("100"); // 10000

如果接口返回的是浮点数，先转成字符串再处理（注意部分浮点数转字符串会变成科学计数法，需要额外兼容）。

2. 所有运算都在整数层面进行 #

不管是加减乘除，全部用分的整数计算，完全没有精度问题：

// 0.2元 + 0.01元 = 20分 + 1分 = 21分
const totalCents = 20 + 1; // 21
// 转成元展示时再除以100
const totalYuan = totalCents / 100; // 0.21

3. 必须处理浮点数时，用高精度十进制库 #

如果因为某些场景不得不处理浮点数（比如第三方接口强制返回浮点数），别用原生运算，改用专门的高精度库，比如JavaScript里的decimal.js或big.js：

import Decimal from 'decimal.js';

// 精确计算1.1 * 100
const result = new Decimal(1.1).times(100).toNumber(); // 110

总结 #

最安全、最省心的方式就是彻底抛弃浮点数，用分的整数完成所有存储和运算。前端负责把用户输入的金额字符串转成整数，后端用int64存储，运算全程用整数，最后展示时再转成小数格式。toFixed()只能作为临时展示的手段，绝对不能用来做运算或转换存储的数值。

内容的提问来源于stack exchange，提问作者Fred Hors