H3.13.4side-effect disclosure in partial failure设计
处置策略需要明确失败项是否已产生副作用
别名: 副作用披露 · unknown side effect · 失败是否已生效
概念解释
一项标着失败，并不自动等于什么都没发生。钱可能已划、信可能已进队列、编号可能已占用，只是回包没到或后续步骤炸了。说清失败项有没有副作用，人才能选择查询、等待、补发还是改参数。不说这一点，失败会被当成「可以安全再点」。这条管副作用的披露，不管状态列表和重试按钮怎么摆。
机制
失败是观察结果，副作用是世界里已经写下的记录。两者在超时、队列、跨服务调用时会分叉。恢复分支完全取决于分叉落在哪：无副作用则可以改完再提交；有副作用则禁止同样的提交，改为对账；未知则先查。披露把分叉说成人能用的句子：「这条没发出去」「这条可能已扣款，请先查看」「这条已创建但未通知对方」。缺这句时，默认脚本是再试，非幂等路径上第二次副作用就发生在「失败」之后。
边界
安全不能描述副作用细节时，仍可分成无 / 有 / 未知三档，并给出对应动作（再试 / 查看 / 求助）。有些副作用几秒后才会出现（异步队列），当下标未知比假装「无」更诚实，并约定何时变为已知。成功项默认有副作用，不必每条再声明；声明的对象是失败与未知项。
怎么落地
- 为每类失败准备副作用档位：确定未发生、确定已发生、未知。档位决定按钮是重试、查看还是两者都有且默认查看。
- 未知项的文案禁止「失败，请重试」作为唯一句；必须出现「可能已完成」。
- 对账入口带着该项的幂等键或业务编号，避免人用肉眼在列表里猜。
- 验证：对「实际已扣款但前端失败」的项走恢复。若人的第一步是再付而不是查看，副作用就没有被说清。