一分钱的差错，放大成百万级资损

支付系统出 bug 和普通业务出 bug 是两种性质的事。普通业务功能不可用，修一修就好。支付系统把钱算错，错误乘以交易量，就是真金白银的资损。一笔优惠金额少算了一分，单看无关紧要，放到百万级日订单上，就是每天稳定地漏掉一万块。资损的可怕之处在于它往往静默，用户不会因为少扣了一分钱来投诉，账面也对得平，直到某天财务对账才发现窟窿。

正因为资损隐蔽且放大效应惊人，防控只能靠层层设防。单一环节再严密也不够，因为攻击面和出错面分布在金额计算、并发扣减、通道对接、结算出款的每一步。可行的策略是从事前、事中、事后三个阶段各布防线，任何一道拦住都能止住损失。

事前，把金额算对这件事做到极致

图：资损防控三阶段防线——事前算对、事中拦住、事后对账，层层设防互为兜底

资损最经典的来源是浮点数。0.1 + 0.2 在 double 下不等于 0.3，而是 0.30000000000000004。单笔看不出，循环累加百万次，误差就累积成可感知的金额偏差。用浮点算钱，等于在系统的地基上埋了一颗慢雷。

1
// 反例，浮点累加误差
2
double total = 0;
3
for (Order o : orders) total += o.getAmount();
4

5
// 正例，统一用分，整数运算
6
long total = 0;
7
for (Order o : orders) total += o.getAmountInCents();

金额一律用整数分或 BigDecimal，这是支付系统的铁律。光这条还不够，要把金额封装成一个 Money 类，禁止裸的 long 或 int 直接参与运算。封装的好处是运算规则收口到一处，溢出、负数、精度这些边界在一个地方统一处理，而不是散落在各处业务代码里各写各的。配上金额计算的单元测试覆盖全场景，零元、最小金额、超大金额溢出、并发场景，事前这道墙才算砌稳。

事中，幂等与并发控制拦住重复扣款

图：并发扣款两种写法对比——先查再扣存在并发窗口导致超扣，原子条件更新用行锁保证安全

金额算对了，不等于扣款动作就安全。网络重试和用户连点会让同一个支付请求到达多次，如果没有幂等，扣一次和扣两次的结果天差地别。给每个支付请求带一个全局唯一的流水号，处理前查流水表是否已处理，已处理的直接幂等返回，不重复扣款。

并发是另一个雷区。余额一百的账户，两个扣款请求同时到达各扣八十，如果先查余额再扣减拆成两步，两个请求都查到一百都以为够，各扣八十，余额变负六十。这就是超扣，典型的资损场景。

1
UPDATE account SET balance = balance - 80
2
WHERE account_id = ? AND balance >= 80

把检查和扣减合并成一条带条件的原子 SQL，让数据库的行锁来保证并发安全。两个请求只有一个能 affected 为 1，另一个因余额不足 affected 为 0。扣款这类关键操作，原子条件更新或分布式锁二选一，不能裸奔。

扣款和出款要分开做双重确认。用户账户扣款是一回事，真正打到银行是另一回事。两者分离，各自校验金额和账户，即便扣款环节藏了 bug，出款前的二次校验还有机会拦下。大额出款再叠一道人工审批，把人和系统串起来。

事后，对账是发现资损的唯一可靠手段

资损一旦发生，靠用户投诉或日常监控发现往往太晚。真正能系统性揪出资损的，是对账。本方账、通道账、银行账三方逐笔比对，任何一处金额或状态对不上，都是资损信号。

对账的价值在于它不依赖任何中间环节的正确性。哪怕事前事中所有防线都失守，只要最终资金流向对不上，对账就会暴露。这是为什么前面掉单治理和后面的分布式事务治理都把对账当兜底，它独立于业务逻辑，是一个外部锚点。差异处理要宁严勿松，每一笔不一致都追根因，不能因为对得上大部分就放过个别。

实时监控是对账的加速版，盯几个关键指标的突变，退款金额异常飙升、某通道成功率骤降、单账户高频交易、对账差异超阈值。任一异常告警，疑似资损立即熔断相关功能止损。监控解决的是响应速度，对账解决的是覆盖完整性，两者互补。

灰度与回滚，限制资损的爆炸半径

图：灰度发布限制资损爆炸半径——错误先在小流量暴露，配合回滚脚本与功能开关实现秒级止血

支付逻辑的任何改动，金额计算、路由规则、对账逻辑，都必须灰度发布。直接全量的风险在于，一个计算错误瞬间波及所有交易，资损在几分钟内就可能堆到不可承受。灰度让错误先在百分之一流量上暴露，损失被限制在小范围内。

支付变更必须灰度

灰度不是可选项。一次新路由规则全量上线，金额计算 bug 在全量交易上生效，几分钟内的资损就可能超过这个功能一年的收益。灰度让错误在百分之一流量上暴露，资损可控。回滚脚本和功能开关要预先备好，发现资损秒级止血，而不是事发再去现找回滚路径。

出款通道这类高风险依赖，还要准备功能开关。发现某个通道异常，一键下线切到备用通道，而不是等它慢慢把资损堆大。

资损发生之后

万一防线全失守，资损已经造成，处置顺序是先止血再追损。紧急熔断出问题的功能防止损失扩大，然后评估规模。能追回的，比如错误出款打到了对方账户，立刻联系银行冻结追回。追不回的计入损失，但必须复盘根因，修复 bug 并补强对应防线。

这套防线的建设成本不低，封装金额类、写全场景测试、搭对账系统、配灰度流程，每一样都要投入。但资损本身的成本更高，一次中等规模的资损事件，往往超过整套防线的建设费用。在资损防控上过度防御是划算的，因为代价是确定的小额，收益是避免不确定的大额。我经历过的大促保障，把零资损作为硬目标，靠的就是这套防线不能有任何一道缺位。