超时可能发生在对方已接收但本地未拿到响应之后，因此重试不能简单等同失败重发。应为同一次表单业务动作建立稳定关联，并由接收端按约定去重，避免连续创建多条线索。
把提交和外部处理分开编号
记录表单记录、发送尝试和接收系统对象之间的关系。一次提交可有多次尝试，但不应每次都被当成新业务。浏览器点击时间或邮箱并非可靠唯一键，访客可能合法多次咨询，应依据真实流程设计可追溯标识。
明确接收确认的含义
接口返回成功可能仅表示进入队列，不一定已经创建CRM对象；超时也不能证明对方没处理。查当前Webhook集成的重试、响应和日志机制，双方约定何时算接收、如何查询处理结果。不要把所有非200状态都盲目无限重试。
在服务端实施安全去重
如需幂等处理，由接收端保存同一动作的稳定标识和结果，重复请求返回已有状态或按规则处理。浏览器隐藏字段可以传上下文，但不能作为无需验证的授权。签名、重放防护和业务去重承担不同职责，日志中不暴露密钥或完整客户资料。
验证异常和恢复路径
用受控样本模拟响应丢失、重复发送和暂时失败，核对只产生约定数量的业务对象，失败能够重试或人工补偿。恢复时先查对方已有记录，不批量重放全部历史。统计真实有效线索而非Webhook请求次数，避免把重试算作增长。
关键区别
一次提交：一项业务意图；可能有多次发送尝试。
接口响应：报告某处理阶段；超时不证明未接收。
幂等关联：识别同一业务动作；不能只按邮箱去重。
怎样确认处理到位
重复尝试不会无故创建重复线索，暂时失败可追踪补偿，双方状态和日志能够对应，密钥及个人资料受控，报表不把重试次数算成新客户。
容易误判的边界
各表单插件与CRM的重试能力不同，本文给出设计判断方法。没有接收端验证前，不宣称勾选自动重试就实现了可靠消息投递。
