一笔订单因接口故障重复进入处理队列，第一笔还在保存，第二笔已经开始重试。此时系统面临的风险很具体，重复扣减额度、重复生成凭证，或者把同一笔损失补偿两次。倘若我们想借用《天之痕》中的投币式铠甲来理解这件事，关键并不是给程序加一层永不失效的防护，而是让一笔预先准备好的资源，在冲击到来时按规则消耗，并且在资源耗尽时如实暴露剩余损失。游戏资料对投币式铠甲的描述是，装备者受到的伤害可以由携带的金钱等值抵扣，直到金钱耗尽。这里有三个不能丢的细节，伤害确实发生了，抵扣会消耗真实资源，资源不足时仍可能有未被抵扣的伤害。把它直接说成防火墙、异常捕获或数据库回滚，都会漏掉最有意思的部分。ABAP 没有一个名为投币式铠甲的内置语句或标准业务对象。不过，在企业系统中，能够承担相似职责的设计并不少见。促销赔付额度吸收订单价差，售后服务预算吸收维修费用，信用准备金吸收约定范围内的坏账风险，接口补偿额度吸收符合规则的重复收费。这些场景共享一条规则，一次事件计算出可确认的损失，从某个受控额度中扣除允许吸收的部分，留下完整记录，并把未覆盖的部分交给正常业务流程处理。先把游戏里的钱和企业里的钱分清楚。角色身上的游戏币由游戏规则直接扣除；企业系统中的账户余额、预算、预提负债和支付账户，性质各不相同。预算余额并不是银行存款，信用额度也不是可以随意支付的现金。我们可以借用投币式铠甲的抵扣算法，却不能因为类比成立，就绕开会计凭证、支付授权或者资金结算。这个边界越清楚，类比越有用。设一次事件的可吸收损失为 650 个额度单位，铠甲账户剩余 1000 个单位，规则允许全额覆盖。系统扣除 650，账户剩余 350，业务对象记录本次覆盖 650，未覆盖损失为零。稍后又发生一笔 500 个单位的损失，账户只能扣除剩余的 350，另有 150 需要进入