一条来自海外子公司的订单消息进入总部的 SAP 系统。消息格式正确，接口也返回了接收成功，但里面的产品编码已经停用。处理程序仍把它写进中间表，夜间作业又按这个编码生成了错误的业务结果。到了第二天，订单处理、异常报表和对账程序都读到了同一条有问题的数据。此时真正棘手的，已经不只是找出最初那条消息，还包括查清它影响了哪些后续对象。把这段业务链放在《仙剑奇侠传 1》的语境里，尸腐肉是一个颇贴切的比喻。物品资料将它描述为沾染尸毒的腐败肉块；一份道具图鉴还记载了投掷后敌方中尸毒、使用后我方也中尸毒的效果。不同版本和资料对细节的记载可能有差异，因此这里抓住两个有用的特征，有害内容能够被带入目标，以及使用者自身也可能承受代价。ABAP 里没有名为尸腐肉的内置对象，也没有一种会自动在业务数据之间传播的程序语言机制。最接近它的，是一份已经失效、污染或不可信的数据，被正常的接口与业务程序当成有效输入，持续带进后续处理。它可能表现为过期的主数据、错误的状态码、重复的事件、被误改的映射关系，或者一条长期重试却始终无法成功的接口消息。这个类比要用得准确，得先分清两种故障。某条记录违反了数据库字段类型或必填约束，写入当场失败，问题通常还停留在入口附近。更像尸腐肉的是另一种情况，记录在技术上完全合法，业务含义却已经坏了。产品编码确实存在于字段里，但产品已停用；币种代码符合字段长度，但金额按另一种币种计算；客户编号能够关联到客户主数据，但消息所属的公司代码不允许使用这位客户。这些数据很容易通过简单的格式检查，直到业务流程走远了才露出问题。我们可以沿着一条订单接口消息看它如何产生影响。外围系统传来一行订单，产品编码、数量和公司代码都不为空。接收程序检查字段长度后，把消息标记为已接收。映射程序按照产