提交超时后再点一次，怎样避免重复订单或重复审批

提交超时后，应先确认原请求的结果，再决定是否重试。防重复不能只靠按钮变灰：刷新页面、重新登录或接口自动重试都可能再次发送请求。建议在软件开发交付范围中约定业务请求标识、服务端去重、结果查询和人工核对入口，让一次业务意图始终能够追到实际单据。

先区分同一次重试和另一笔新业务

假设用户提交一张采购申请，浏览器未收到响应。再次查询或重试这张申请应沿用原请求标识；用户明确创建另一张内容相同的申请，则属于新的业务意图。不能仅凭字段完全相同就合并，也不能每次点按钮都生成新标识。

Amazon Builders’ Library讨论了由调用方提供请求标识来表达这种意图。项目中还应约定标识所属组织、操作类型及目标记录，防止不同业务误用同一标识；它用于关联请求，不应充当访问单据的授权凭据。

页面需要给出可行动的状态

建议区分已受理、处理中、已完成、明确失败与结果待确认。技术请求成功只代表对应接口接受或完成了约定动作，不等于审批已通过。页面应显示可追查的请求号或单据号，并说明下一步是查看、等待、修正还是联系指定处理人。

HTTP 语义规范不支持在缺少安全依据时自动重试非幂等请求。因此，“遇到超时自动再发”必须以真实接口契约和测试为前提，不能只在前端增加重试次数。

把去重边界写成能追查的业务约定

建议保存请求与实际单据的关联，并约定重复请求返回哪个结果。同一请求标识却改变金额、对象或审批动作时，应识别为不一致，不能把新内容当作原操作成功返回。原单据后来被撤销，也不能因旧请求迟到而无意重新创建。

还需说明去重记录保留多久、过期后怎样查原单，以及长时间未确认由谁处理。保留期限应覆盖实际重试和业务核对需求，没有适用于所有系统的统一时长。后台任务和外部系统写入是否在同一保证范围内，应单独列明；本地只生成一单，并不自动证明外部系统没有收到两次动作。

验收要切断响应，而不只是让请求报错

1. 正常提交后连续重复发送同一请求，核对仍指向同一业务单据。
2. 在业务已写入、响应尚未到达浏览器时中断连接，再恢复查询，确认没有第二张单。
3. 关闭页面后重新进入，确认可以找回原请求，而不是被迫重新创建。
4. 以同一标识提交不同内容，检查明确拒绝或冲突结果。
5. 重复发送下游回调，核对审批流转、库存动作等约定副作用没有再次发生。

这些用例需要测试环境中的受控故障，不应随意中断生产业务。证据至少保留请求标识、单据号、操作时间、最终业务状态和相关系统结果。日志中有两次请求可以是正常重试，业务记录出现两份才可能是错误，不能只数日志条目。

无法确认结果时，谁来恢复业务

长期待确认的请求应进入可处理清单，注明负责系统、核对人和下一步，不直接批量重发。跨系统由谁提供权威结果，可按接口与数据归属确定。若入口来自大屏异常派单，可接着核对异常到工单的回写路径，确保人员看到的是原工单的后续状态，而不是为消除提示再派一单。