一张采购订单正在等待审批。审批人打开工作台，看到供应商、金额和公司代码都很正常，按下批准后，系统也返回了成功消息。几个小时后，财务发现审批记录写到了另一家公司的流程实例上。程序没有崩溃，数据库没有报错，执行者甚至拥有相应的权限，但业务动作落在了错误的对象上。这个场景很适合借《仙剑奇侠传 1》里的紫罂粟来理解。游戏资料对紫罂粟的描述是，服食者产生幻觉，敌我不分；另一份道具资料把它的战斗效果写作使敌人进入疯魔状态，并记载使用后己方也会受到疯魔影响。不同资料对回合数和数值的记法可以另行核对，但这里最有启发性的特征很明确，受影响的一方失去辨认目标的能力，施加影响的一方还可能遭到反噬。:chatgpt-content-reference{index=“0”}ABAP 当然没有叫作紫罂粟的内置语句或标准对象。若把道具效果映射到企业应用，我会把它看作一种目标身份错认。系统原本应该对业务对象甲执行动作，却因为关联、键值、上下文或权限边界处理有误，对业务对象乙执行了动作。更棘手的是，错误操作可能更新共享数据，触发后续流程，让原本正确的一侧也承担损失。这比单纯把程序停住更接近紫罂粟的味道。游戏里的敌我，是阵营关系。业务系统里的敌我，则是本次请求允许触及与不允许触及的边界。边界可以是公司代码、销售组织、业务伙伴、订单号、租户、流程实例，也可以是同一张订单的抬头与行项目。程序需要知道当前操作者是谁、当前请求针对谁、准备修改谁，以及修改结果会影响谁。只要其中一个身份在数据流中被悄悄换掉，代码即使每一行都合法，也可能做出完全错误的业务决定。一家跨国企业的总部与海外子公司都使用 SAP S/4HANA Cloud Private Edition 时，这种问题尤其容易理解。采购审批界面可能同时展