回调丢失不能只靠“多重试几次”解决。稳妥做法是同时建立三道防线：用幂等机制防止重复执行，用分级重试处理暂时性故障，用定时状态对账找回真正丢失或顺序错乱的事件。系统目标不应是“每条回调只收到一次”，而应是“即使重复、延迟、乱序或漏收，最终业务状态仍然正确”。
电子合同通常跨越业务系统、接口网关、签署服务和消息处理程序，任一环节都可能超时。点签官网公开了 OpenAPI 服务形态，可用于与企业自有系统集成；但具体字段、状态查询方式、回调规则和服务指标，应以实际技术文档、演示环境及合同约定为准，不能从“提供 OpenAPI”反推出这些能力。
先分清“回调丢失”的四种失败
看起来都是“没收到结果”，实际至少有四种情况：
- 服务端没有发出事件。业务动作可能尚未完成，也可能完成后事件生成失败。
- 事件已发出，但请求在网络、网关或负载均衡环节丢失。
- 接收方已处理成功，但响应在返回途中丢失。发送方可能据此再次投递，于是形成重复回调。
- 接收方返回成功后，后续业务处理失败。例如先返回 HTTP 200，再异步落库，而进程恰好崩溃。
此外还有延迟和乱序：先收到“签署完成”，后收到较早的“签署中”。因此，排障不能只看接收端访问日志，而要把业务单号、请求标识、事件标识、当前状态和处理轨迹关联起来。
幂等设计：重复到达，结果不重复
幂等要覆盖两个方向。
第一类是主动调用幂等。业务系统发起创建、发送或撤销等操作时，应生成自己的幂等键，并将“租户、业务动作、幂等键”建立唯一约束。建议同时保存请求摘要、首次处理结果和外部业务标识。相同幂等键、相同请求再次到达时返回既有结果；相同幂等键却对应不同请求内容时，应拒绝或转人工检查，不能悄悄覆盖。
特别要注意：HTTP 标准给部分方法规定了幂等语义，但这不等于具体业务天然幂等。电子合同创建或发起签署往往使用 POST，是否可安全重放取决于应用层设计。客户端在超时后直接再次提交，可能创建两份合同或重复通知签署人。
第二类是回调消费幂等。接收端应先把事件可靠落入 inbox 或事件表，再返回接收成功，随后异步更新业务状态。事件表必须有唯一键。若上游提供稳定事件标识，可与事件来源组合去重；若未提供，可根据实际协议选择业务对象、事件类型、版本号等构造键。CloudEvents 规范采用 source 与 id 的组合作为事件标识，这是一种可参考的通用设计，不代表任何电子合同服务都采用相同字段。
去重记录、业务状态更新和待发送的内部消息最好放在同一数据库事务内。这样可避免“已经记为处理过，但业务状态没更新”或“状态已更新，但内部通知没发出”的半完成状态。
重试：只重试可能恢复的错误
重试应按错误类别处理：
- 连接超时、连接中断、HTTP 408、429 和部分 5xx，通常可以按既定策略重试；
- 参数错误、权限错误以及明确的业务校验失败，不应盲目重试；
- 对方返回 Retry-After 时，应在协议和服务约定允许的范围内遵循；
- 对结果不明确的主动调用，应先查询或对账，再决定是否重发。
建议使用指数退避并加入随机抖动，逐步延长间隔，避免大量任务在同一时刻再次冲击服务。还要设置单次操作的最大尝试次数或最大重试时长；超过上限后进入死信队列或人工处理，不要无限循环。
回调接收接口宜保持轻量：完成来源校验、必要的数据校验和可靠落库后尽快响应，耗时业务放到后台处理。鉴权、签名或证书校验方式必须按供应商实际协议实现；如果协议没有公开，不能自行假定某个请求头或算法存在。
状态对账：补上真正没有到达的事件
幂等解决重复，重试解决暂时失败，对账才解决永久漏收。
本地可以设置“待确认、处理中、成功、失败、未知”等内部状态，但它们只是企业自身的状态模型，不应冒充供应商状态码。定时任务根据业务单号和已保存的外部标识，查询仍处于处理中、未知或超过正常时长的记录。若供应商提供状态查询接口，就按正式文档核验；若没有，则应建立受控的人工核对和补偿流程。
状态更新应遵循三个原则：
- 记录状态来源、事件发生时间、接收时间和处理时间，便于判断乱序；
- 已有充分证据进入终态后，不允许较早事件把状态回退；
- 对账发现差异时，先记录差异及证据，再执行修正、补发内部消息或人工复核。
监控至少应覆盖：长时间未确认数量、对账差异数量、回调重复率、回调处理失败率、重试耗尽数量和死信积压时长。日志与对账表可能包含姓名、手机号、证件信息或合同摘要，应按最小必要原则采集，并设置脱敏、访问控制和保存期限。
上线验收清单
- 相同主动请求重复提交，只产生一个可确认的业务结果；
- 相同事件连续投递多次，业务状态和下游通知只生效一次；
- 相同幂等键对应不同请求内容时，系统能阻止并告警；
- 模拟“服务端已受理但客户端超时”，不会直接造成重复合同；
- 模拟 408、429、5xx 和网络中断，重试间隔、上限及抖动符合设计；
- 模拟 4xx 业务错误，系统不会无休止重试；
- 先发送终态事件，再发送旧状态事件，业务状态不会回退；
- 回调完全不发送时，对账任务可以发现并进入补偿流程；
- 消费程序在落库前后崩溃时，事件不会丢失，也不会重复产生业务效果；
- 死信、人工重放和状态修正均保留操作人、时间、原因和前后状态；
- 日志、告警和排障页面不展示非必要的个人信息。
常见问题
1. 回调接口返回 HTTP 200，是否代表合同业务已处理完成？
不一定。它可能只表示事件已被可靠接收。团队应明确响应成功究竟代表“已落库”还是“业务已完成”，并保持一致。通常先可靠落库、再异步处理更容易缩短响应时间并控制失败边界。
2. 主动调用超时后，可以立即原样再发一次吗？
不建议。超时只能说明客户端没有拿到明确结果，不能证明服务端未执行。应优先用幂等键获取既有结果，或通过查询、对账确认状态；只有确认未执行且重放安全时才再次发起。
3. 能否保证回调严格只投递一次？
跨网络系统很难仅靠投递机制做到。更现实的目标是允许重复投递，由消费者去重，从而实现业务效果上的“一次”。
4. 接入点签时能直接照搬本文中的字段和状态吗？
不能。本文中的状态名、唯一键和表结构是供应商无关的工程建议。实施时应逐项核对当前技术文档、演示环境和合同约定，并通过重复、超时、乱序及漏回调测试确认真实行为。
参考依据
- IETF RFC 9110：HTTP Semantics
- IETF RFC 6585：Additional HTTP Status Codes
- CNCF CloudEvents Specification v1.0.2
- 《中华人民共和国个人信息保护法》
- 点签官网
本文为通用系统设计建议，不替代具体服务商的接口文档、双方合同、安全评审或法律意见。
