0.1 + 0.2 为什么不等于 0.3：vibe 项目的金额计算精度实战

一分钱对不上，账就没法结：先说一个真实感很强的教训

先讲一个虚构的教学例子。小铺“青禾杂货”是个一人小店，老板用 AI 搭了个在线下单页：满 100 减 10，运费 6 块，支持微信和支付宝。上线第一周，有顾客截图来问：三件商品分别是 19.99、29.99、49.99，加起来明明是 99.97，页面却显示满减后应付 95.97，可他实际被扣了 95.96。差一分钱。老板去查，发现同一笔订单在三个地方是三个数：下单页算出来 95.97，支付接口传过去 95.96，数据库里存的是 95.96999999999999。客服解释不清，顾客觉得被多扣了，老板自己也不知道该信哪一个数。

这就是金额计算最常见的死法：不是大数算错，而是小数点后那一两分钱，在不同的地方被不同的方式处理了。金额不像普通数字，它背后是真金白银，是对账单、发票和退款的依据。一分钱对不上，轻则顾客投诉，重则月底对账差出几千块，查三天也查不出是哪一笔漏的。

本文讲的就是怎么让 vibe 项目里的钱算得准：从为什么浮点数算不准钱，到“只存整数”这条铁律，到舍入、折扣、税费、分摊、多币种这些具体场景，再到前后端分工和上线前的测试清单。以下示例均为虚构的教学示例，应用名与数字均为为讲解而构造的简化版本。

一、为什么 0.1 + 0.2 不等于 0.3

先把根因说清楚，不然所有修法都是碰运气。电脑里的小数，绝大多数是用二进制浮点数存的，也就是 IEEE 754 双精度浮点数。0.1 这个十进制小数，换成二进制是无限循环的，电脑只能截取前 53 位存下来，于是存进去的那个数本身就已经不是 0.1，而是 0.1000000000000000055511151231257827。0.2 也一样。两个“差不多”的数一加，结果就是 0.30000000000000004。这不是某个语言的 bug，JavaScript、Python、Go、Java 默认的 double 全都这样。

平时写代码感觉不到，是因为显示的时候会被修掉：console.log(0.1 + 0.2) 打印出来看着像 0.30000000000000004，但很多界面会用 toFixed(2) 把它抹平成 0.30。问题在于，抹平只发生在显示那一刻，真正参与运算、比较、入库的那个数，始终是那个带尾巴的数。等到金额累加几百次、再乘以税率、再分摊到几个人头上，尾巴就攒成了一分钱，甚至几块钱。

新手最容易踩的三个坑，都长在这个根因上。第一是拿浮点数做相等比较：if (total === 99.97) 这种写法，total 是 99.96999999999999 的时候就永远进不去，订单状态就卡住了。第二是反复用 toFixed 修修补补：toFixed 返回的是字符串，拿字符串再去参与下一次加减，等于在错误的基础上继续算，而且不同语言、不同浏览器的舍入行为还不完全一样。第三是以为“钱小、无所谓”：一笔订单差一分钱确实无所谓，但一千笔订单每笔都往同一个方向偏，月底对账就会差出十几块，而这十几块没有一笔订单能单独解释。

// 错：浮点数直接算钱
const total = 19.99 + 29.99 + 49.99; // 99.96999999999999
console.log(total === 99.97);        // false，比较永远失败
console.log(total.toFixed(2));       // "99.97"，但这只是显示修掉了尾巴

// 对：先换成整数分，再算
const totalCents = 1999 + 2999 + 4999; // 9997，精确
console.log(totalCents === 9997);      // true

二、第一条铁律：钱只存整数，最小单位

金额计算只有一条铁律：从入口到数据库，钱只以整数的最小单位流转。人民币就是分，美元就是美分，日元本身就是最小单位，不用再除。19.99 元存成 1999，29.99 元存成 2999，中间所有的加减乘都对整数做，最后只在展示给人看的那一刻，才除以 100、格式化成“¥99.97”。整数加减乘是精确的，没有尾巴，也就没有误差攒起来的空间。

这条铁律要落到四个地方才算数，缺一个都会漏。第一是数据库字段：金额列用 BIGINT 存分，或者用 DECIMAL(19,4) 这类定点类型，绝不用 FLOAT 或 DOUBLE 存钱。DECIMAL 是定点数，19.99 存进去就是 19.99，不会变出尾巴；但它仍然要求你在代码里想清楚单位，DECIMAL 存“元”还是存“分”必须全站统一。第二是接口传输：前后端之间传 1999 这样的整数分，不要传 19.99 这样的浮点数；JSON 里 19.99 到对方手里还是浮点数，问题一点没解决。第三是前端状态：购物车里的单价、小计、总计，全部按分算，页面上显示的“¥”只是格式化结果。第四是日志与对账：日志里记的金额也要记分，或者同时记“分 + 币种”，否则出问题时连复现都复现不了。

有人会问：整数分够不够用？一笔订单最多几百万，1999 这种量级离 BIGINT 的上限还差十万八千里。真正不够用的场景是两种：一种是单价本身带三位以上小数，比如油价、汇率换算出来的单价；一种是分摊到很多人头上，每人要精确到厘。这两种情况的解法不是回到浮点数，而是把最小单位再往下取一位：内部统一用“厘”（1 元 = 1000 厘）或者用定点小数 DECIMAL(19,4)，只在最后展示和结算时再舍入到分。关键不是“分”这个具体单位，而是“全程整数或定点、只在边界舍入一次”这个原则。

做法	存什么	结果
浮点数存元	DOUBLE 19.99	0.1 + 0.2 出尾巴，越算越偏
整数存分	BIGINT 1999	加减精确，推荐做法
定点数存元	DECIMAL(19,4) 19.9900	精确，但要全站统一单位
整数存厘	BIGINT 19990	需要三位小数精度时用

还有一个细节：不要在代码里混用单位。见过最典型的事故是，后端存分、前端按元算、支付接口按分传，三个地方各写各的换算，某次改版只改了其中两处，订单金额直接差了一百倍。做法是把单位写进名字里：amountCents、priceCents、totalCents，看到名字就知道单位；再封装两个函数 fromYuan 和 toYuan，全站只允许通过这两个函数换算，别的任何地方都不许手写 * 100 或 / 100。

三、舍入：只在最后关口做一次，而且要说明规则

整数能解决加减，但乘除迟早会碰上除不尽。比如 100 元打 9 折是 90 元，没问题；但 99 元打 9 折是 89.1 元，89.1 元换成分是 8910 分，也没问题；真正麻烦的是 10 元三个人分，每人 3.333…元，分这个单位下不去。这时候就必须舍入，而舍入的规矩是：只在最后关口做一次，中间过程一律不舍入。

“只在最后关口做一次”是什么意思？以“满 100 减 10 再打 9 折再加税”为例，正确的顺序是：全程用分做整数运算，折扣和税都先算出精确的中间值（可以用厘过渡），到最后要落到“应付金额”这一个数的时候，再做一次舍入。错误的做法是每算一步就 toFixed(2) 一次：满减后舍一次、折扣后舍一次、税后舍一次，三次舍入的误差方向可能相同，最后差出两三分钱，而且每一步的误差都藏在中间结果里，查账时根本看不出来是哪一步偏的。

舍入规则本身也要选好，并且写进文档、告诉用户。最常见的是四舍五入（HALF_UP）：0.5 往上进。银行和财务系统常用银行家舍入（HALF_EVEN）：0.5 向最近的偶数靠，2.5 舍成 2，3.5 舍成 4，长期来看正负误差能互相抵消。还有直接舍去（DOWN）和直接进位（UP），前者常用于“给用户的优惠金额向下取整”，后者常用于“税费向上取整、宁可多收一分税也不能少交”。没有哪种规则是放之四海而皆准的，关键是全站只用一种默认规则，例外情况单独注明，而不是让每个开发凭感觉选。

// 错：每步都舍入，误差层层叠加
let t = (99.97 - 10).toFixed(2);   // "89.97"
t = (parseFloat(t) * 0.9).toFixed(2); // "80.97"
t = (parseFloat(t) * 1.06).toFixed(2); // "85.83"

// 对：整数分全程运算，只在最后舍入一次
// 9997 分 - 1000 分 = 8997 分；8997 * 9 / 10 = 8097.3 分；
// 8097.3 * 106 / 100 = 8583.078 分；最后 HALF_UP 得 8583 分 = ¥85.83
function roundHalfUp(numerator, denominator) {
  return Math.floor((numerator * 2 + denominator) / (denominator * 2));
  // 整数运算实现四舍五入，避免浮点数介入
}
const payableCents = roundHalfUp(8997 * 9 * 106, 10 * 100); // 8583

Python 的 Decimal 和 Java 的 BigDecimal 是专门干这个的：Decimal("99.97") 这种字符串构造的定点数，加减乘除都精确，舍入规则用 quantize 显式指定。但要注意，Decimal(0.1) 这种从浮点数构造的写法会把浮点数的尾巴原样带进来，必须用 Decimal("0.1") 从字符串构造。Go 没有内置的 Decimal，一般用 shopspring/decimal 这类库，或者坚持整数分。语言和库可以换，原则不变：钱的运算不许经过二进制浮点数。

四、折扣、税费、分摊：先算总账，再分钱

折扣、税费和分摊是金额 bug 最集中的地方，因为它们都涉及“一个总数怎么拆”。共同的原则是：先算总账，再分钱；分钱的时候，余数只能落在一个地方，而且要事先说好落在哪里。

先说折扣。满减、满折、优惠券叠加，最容易错的是叠加顺序。同样是“满 100 减 10”和“9 折”，先减后折和先折后减的结果不一样：100 元先减 10 得 90，再 9 折是 81；先 9 折得 90，再减 10 是 80。差 1 块钱，用户截图一算就能发现。做法是把叠加顺序写成一条明确的规则，写进代码注释和帮助文档，比如“固定金额优惠先于比例优惠，优惠券最后”，并且用测试把每种组合的顺序锁死。不要让顺序藏在代码执行的先后里，藏着的东西迟早会被某次重构改掉。

再说税费。税最大的坑是“含税价还是不含税价”。商品标价 100 元，税率 6%，如果标价是含税价，税额是 100 - 100 / 1.06 = 5.66 元；如果是不含税价，税额是 100 * 0.06 = 6 元。两种算法差 0.34 元，发票一开就对不上。做法是：数据库里同时存“不含税金额”和“税额”两个字段，标价是含税还是不含税做成配置项而不是约定俗成；展示给用户的税额，永远从这两个字段算出来，而不是现场反推。跨境场景还要留一个心眼：不同地区的税率不同，税是按购买者所在地算还是按商家所在地算，写死之前先确认业务规则。

最后说分摊，也是最容易差一分钱的地方。10 元三个人分，每人 3.33 元，三个 3.33 加起来是 9.99，少了一分钱。这一分钱去哪了？正确的做法是“最大余数法”：先每人分 333 分，剩下的 1 分按事先定好的规则给一个人——比如给第一个人、给金额最大的人、或者随机给一个人，但规则必须固定、可复现。红包、拼单、佣金分成、退款分摊，全是同一个问题。千万不要用“每人单独四舍五入”：三个人每人 3.33 元是四舍五入的结果，但三个 3.33 加起来不等于 10 元，分账表和总账永远对不上。

// 最大余数法：1000 分分给 3 个人
function splitCents(total, n) {
  const base = Math.floor(total / n); // 每人 333 分
  const rest = total - base * n;      // 余 1 分
  const parts = Array(n).fill(base);
  for (let i = 0; i < rest; i++) parts[i] += 1; // 余数依次给前几个人
  return parts; // [334, 333, 333]，加起来正好 1000 分
}

五、多币种：小数位数不是全世界都一样

项目一接多币种，金额精度的问题就翻倍。第一个坑是小数位数：绝大多数货币是两位小数，但日元、韩元是零位小数，100 日元就是 100，不存在“100.00 日元”；而有些货币历史上用过三位小数。做法是：金额表里必须同时存币种（currency）和最小单位金额（amountMinor），展示时按币种查小数位数来格式化，绝不能假设所有币种都是除以 100。ISO 4217 的货币代码和对应的小数位数是公开标准，直接用现成的货币库，不要自己手写一张映射表——手写的表迟早会漏掉某个币种。

第二个坑是汇率。汇率本身是个高精度小数，换算时要先定两件事：用哪个时点的汇率，以及换算结果舍入到几位。正确的做法是：汇率取自明确的来源并记录快照（哪一天、哪个接口、哪个值），同一笔订单从下单到结算用同一个快照汇率，不要让汇率在流程中间变掉；换算用高精度定点数算，只在落到目标币种的最小单位时舍入一次。千万不要拿前端实时查到的汇率去算后端结算金额，前后端查到的汇率可能差一个点，订单金额就对不上了。

第三个坑是币种混算。不同币种的金额绝不能直接相加：100 美元加 100 日元等于多少？没有意义。正确的做法是：所有运算都在同一币种内完成，跨币种汇总时先按快照汇率统一换算成本位币，再相加；报表上同时展示原币种金额和本位币金额。数据库里给金额加币种字段，并且给“币种 + 金额”建唯一约束的校验，避免某次迁移把美元的数写进了日元的列。

六、前后端各管什么：后端是唯一真相

金额算错，很多时候不是算法错，而是前后端各算了一遍，算得不一样。前端为了让页面立刻响应，会先在本地算一个小计和总计给用户看；后端收到订单后又会按自己的逻辑重算一遍。两边用的折扣顺序、舍入规则、税率来源但凡有一处不同，用户看到的数和实际扣款的数就会差一分钱。原则是：前端只负责展示，后端是唯一真相。前端可以算，但算出来的数只能用来展示，最终以服务端返回的金额为准；下单请求里只传“买了什么、用了哪张券”，不传“我算出来的总价”，后端收到后按商品和规则重算，算出来的数才是要扣的数。

展示环节也有讲究。格式化只做一件事：把整数分变成人能读的样子。人民币 1999 分显示成“¥19.99”，美元 1999 美分显示成“$19.99”，日元 1999 显示成“¥1,999”。用 Intl.NumberFormat 这类系统内置的格式化器，不要自己拼字符串：千分位、小数点、货币符号的位置，不同语言环境是不一样的，自己拼迟早拼错一个。还有一个常见错误：把格式化后的字符串再拿回去参与运算——“¥19.99”这个字符串是给人看的，不是给代码算的，算钱永远用整数分。

数据库选型再补一句：PostgreSQL 里存钱，优先用 BIGINT 存分，简单直接；如果业务确实需要四位以上小数精度，再用 NUMERIC(19,4)。MySQL 里对应的是 BIGINT 或 DECIMAL(19,4)。不管选哪种，迁移脚本里要把旧的 FLOAT/DOUBLE 列一次性改掉，并且写一个校验脚本：把所有历史订单按新规则重算一遍，重算结果和原记录差超过一分钱的，全部列出来人工复核。不要假设旧数据是对的——旧数据就是用错的方法算出来的。

七、七个必测用例：上线之前先跑一遍

金额模块没有“大概对了”这个说法，测试用例要覆盖所有边界。下面这七个用例，建议直接写进自动化测试，每次改金额逻辑都跑一遍：

用例	输入	期望
经典浮点陷阱	0.1 + 0.2	按分算是 30 分，不出 0.30000000000000004
半分舍入	2.5 分按 HALF_UP / HALF_EVEN	规则事先定好，两种结果都写进测试
三人分 10 元	1000 分 / 3 人	[334, 333, 333]，总和正好 1000
折扣叠加顺序	满 100 减 10 再 9 折	81 元，与文档写的顺序一致
零位小数货币	100 日元	展示为 ¥100，不出现 .00
退款与负数	退 19.99 元中的一件	退款金额为负的整数分，不出 -1998.9999
大额边界	单笔 999,999,999 分	不溢出，总计与明细之和一致

除了这七个，还有两个习惯值得养成。第一是“对账测试”：每天跑一个定时任务，把当天的订单总金额、退款总金额、实收总金额三个数按整数分重算一遍，三个数之间的勾稽关系必须成立，差一分钱就报警。第二是“显示测试”：把格式化结果截图存下来，人工看一眼有没有出现“¥19.9900000001”这种带尾巴的数——机器测试能抓住逻辑错，但显示错往往要人眼才看得出来。

八、上线前检查清单

最后是一张可以直接照着打勾的清单。第一，全站金额字段是不是整数分或定点数，FLOAT/DOUBLE 有没有清干净。第二，单位有没有写进变量名和字段名，* 100 和 / 100 是不是只出现在两个封装函数里。第三，舍入是不是只在最后关口做一次，规则是不是全站统一、写进了文档。第四，折扣叠加顺序、含税还是不含税、余数归属，这三条业务规则有没有白纸黑字写下来。第五，多币种的小数位数是不是按币种查表，汇率快照有没有存下来。第六，下单接口是不是只传商品和券、不传前端算好的总价。第七，七个必测用例有没有进自动化测试，对账任务有没有跑起来。

如果清单里有一项答不上来，金额模块就先别上线。钱算错的代价从来不在代码里，而在客服、财务和信任上：一分钱的账对不上，用户记住的是“这家店算账有问题”。反过来，只要守住“整数流转、边界舍入一次、后端唯一真相”这三条，金额模块就能做到“算出来的数、显示的数、扣掉的数、账上的数”四个数永远一致。这就是金额精度这件事的全部要义：不追求多么高明的算法，只追求每一步都有据可查、每分钱都有去处。