一张销售订单今天保存成功，明天运行的交货作业却把它挑了出来，报一次错。作业次日照常执行，同一张订单又报一次错。过了几天，业务人员看到的仍然只是订单暂时无法交货，技术团队看到的却是不断累积的失败记录、重复调用和人工处理时间。这种故障很适合借《仙剑奇侠传 1》里的金蚕蛊来理解。
这里得把物品认准。金蚕蛊是使目标中毒、在后续回合持续损血的毒蛊；金蚕王则与提升修行有关。两者名字接近，拿来解释 ABAP 时却会走向完全不同的方向。金蚕蛊适合类比一种状态已经进入业务流程、每次后续处理都会继续造成损失的故障。游戏物品资料对两者的描述可见文末参考资料。
ABAP 没有名为金蚕蛊的语言构造，也没有一个标准类可以把业务对象设为中毒。不过，企业系统里确实存在与它相似的现象。某个错误值被保存，某项条件没有得到纠正，一个失败任务被无限重试，或者一段有缺陷的规则每天作用于新数据。单次运行造成的伤害也许不大，处理轮次一多，损失就会持续扩大。
类比的关键在于分清三个时刻。施蛊对应问题进入系统的时刻，可能是保存了一条不完整的主数据，也可能是启用了错误的配置。发作对应后续处理再次接触该状态，可能由用户操作、后台作业、接口消息或者业务对象的保存过程触发。解蛊则需要移除造成反复失败的条件，并确认已经受影响的数据得到处理。只让当前一次程序执行成功，未必能消除后续回合的损失。
我们可以从一个常见的企业场景往下看。总部与海外子公司共用一套订单处理流程，海外公司的一批物料缺少某项交货所需的维护数据。订单创建界面允许保存，日间操作看起来也没有异常。夜间交货作业逐笔处理时，这批订单反复失败。第二天客服再次尝试，订单继续失败；接口收到失败结果后重新发送，又制造了更多待处理记录。这里的金蚕蛊并不是某一行致命代码，而是缺失的业务条件与重复处理机制相互叠加。
