先给出可以用于决策的结论
先给每个业务事件分配稳定唯一标识，并在写入前查询或记录处理状态。对连接超时、临时限流等可恢复错误采用有限次数和指数退避；对字段缺失、权限不足和业务规则拒绝，不应自动重复，而是进入可读的异常队列。跨系统流程需记录每一步的外部编号、请求摘要和结果，部分成功时根据业务决定继续、撤销、人工确认或补写。补偿不一定是技术上的反向操作，例如已经发送的邮件无法真正收回，可能需要发送更正并通知负责人。关键流程还要有定时对账，发现工作流认为成功但目标系统实际未落账的情况。
判断前需要确认哪些条件
同一个问题在不同企业、数据和项目阶段下可能有不同答案。建议先核对以下条件，再把网上的通用结论代入自己的项目。
建议按什么顺序推进
先明确目标与边界
为事件、业务对象和每个写入动作建立唯一键。
验证关键依赖
按错误类型配置重试、停止、补偿或人工队列。
形成可评审成果
保存步骤状态、外部编号、输入摘要和错误原因。
用真实结果决定下一步
通过故障注入与定时对账验证最终一致性。
放到实际业务中如何理解
工作流在ERP创建订单后等待响应超时。系统不能立即再次创建，而应使用客户订单号查询ERP是否已有记录；若已存在则继续后续步骤，若确认不存在才重试。若ERP成功但CRM更新失败，应保留ERP订单号并补写CRM，而不是回滚或重复整个流程。 示例不代表特定客户业绩，实际结论需要结合企业自己的业务量、样本、系统和责任边界验证。
最容易踩的坑
所有节点统一设置无限重试
只记录技术错误，没有业务对象和外部编号
部分成功后从头重跑整个工作流
最终应该怎样验收或确认
测试应主动制造重复事件、超时、限流、权限不足、字段错误和部分成功，验证不会产生重复业务记录；异常能够进入正确队列，告警包含可处理信息，补偿与对账结果均有审计证据。
准备与供应商或内部团队沟通时，建议带上当前流程、代表性样本、现有系统、计划时间和预算等级。先把未知项明确标注，再决定采用诊断、PoC、固定范围项目或持续研发，通常比直接索要一个缺少边界的价格和工期更可靠。