回调里同步查了三次远程接口，平均 12 秒，渠道 5 秒就断开并重推，同一事件一天推了 4 次。乍看像缓存或者权限的锅，追下去往往不是。
time curl -X POST http://127.0.0.1:8080/callback -d @event.json
追下去是这么回事：耗时的业务逻辑全压在回调的同步链路上，渠道等不到响应就判失败。重推又走一遍完整逻辑，队列越堆越长。
「回调超时重复推送」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。报错里带路径的，先去看那个路径在不在、权限对不对。
同一份配置存在多处的，先确认改的是被加载的那一份。
具体做法是，入口只做验签和落库 立刻返回 success；业务处理改成队列异步消费；消费端按事件 id 幂等；把同步链路耗时压到 200 毫秒以内。
验收就看一点，回调响应稳定在 200 毫秒内 渠道后台不再出现重推记录。