Webhook 在演示里几乎总是成功，在生产里却常因网络抖动、对端超时或重复投递变成丢单或重复记账。正确的错误处理与重试策略，是为了避免数据丢失与重复业务。
结构对照：Overview Of Webhook Error Handling and Retry Strategies in Odoo 19。
一、两个方向，两类问题
- 出站 Webhook：Odoo 把信息发给外部（自动化规则、服务器动作或自定义代码）。失败主因：对端无响应、慢、易错。
- 入站 Webhook：外部调用 Odoo 自定义控制器。失败主因：Odoo 抛错、数据不合法、事件重复投递。
二、出站失败怎么处理
常见坑：直接 requests.post() 却不设超时、不处理异常。对端一慢，就会拖住 Odoo Worker；失败时异常若未妥善处理，会影响稳定性。
更好的做法：
- 设置请求 timeout
- 捕获
requests.exceptions.RequestException - 完整记录失败日志
- 跟踪每次调用状态
- 失败后可重试
示例：自定义模型 webhook.delivery 可含字段 destination、payload、status、attempts、next_try。再用计划动作扫描失败记录，按退避重试：1 分钟 → 5 分钟 → 30 分钟 → 更长。达到上限后标记人工处理。
这样重试离开用户请求线程，避免慢外部服务拖死 Worker。
三、入站失败怎么处理
入站优先：校验请求并快速响应。控制器建议顺序：
- 校验签名或认证
- 校验载荷
- 检查事件是否已处理（幂等）
- 记录事件
- 返回合适的 HTTP 响应
- 重业务（开票、出库等）必要时异步处理
四、处理重复 Webhook
对端若未在预期内收到确认，会重发。必须把去重写进设计：用事件唯一 ID 作幂等键，处理前先查是否已处理，避免同一支付记两笔。
五、返回正确的 HTTP 响应
- 2xx：通常表示投递/接受成功
- 4xx：请求本身有问题
- 5xx：服务端问题，发送方往往会重试
业务失败却返回成功，会掩盖问题并造成不一致。响应必须如实反映结果。
六、设置重试上限
不要无限重试。达到上限后：停止重试、记录原因、标记待审、通知负责人。避免对着已坏终点狂重试，也便于发现持续性故障。
七、小结与国内补充
可靠 Webhook 不只“能发能收”，还要：超时、错误处理、日志、重试、去重、重试上限；入站幂等；出站与用户请求解耦。另建议每日与外部系统对账单据量，监控死信堆积。
八、FAQ
为什么要重试？网络会抖、服务会短暂失败，重试比直接丢数据更稳。
如何避免重复？保存事件唯一 ID，已处理则跳过。
要不要无限重试？不要。设上限，超限转人工。
中国Odoo网原创中文改写｜保留出站/入站/幂等/响应码/FAQ 全要点。Odoo用户手册 · 中文文档 · 实操。