读超时后原样再 POST 一次会话里会出现两份相同跟进。调用方认为超时等于失败观察方已经收到。两边描述的都是事实错在把不确定态映射成了失败态。企业微信消息通道很老实你提交两次会话里就两次。它不会因为你「只是想确认一下」就合并。这个坑在网关变慢的下午特别容易出现。下游已经写入你这边读超时拦截器再打一枪客户以为你在催。超时不蕴含「未写入」投递一旦被通道接受会话侧可能已经落库。调用方读超时只说明回执未在预算内返回。网关变慢、对端已写、客户端先断开是典型双写路径。HTTP 超时、连接重置、中间层 502 同属不确定正确动作是按业务键查询已成功则停止确认未投递再决定是否补。不要把超时丢进万能重试。示意importrequestsdefdeliver_once(url,headers,body,biz_key):try:rrequests.post(url,headersheaders,jsonbody,timeout20)r.raise_for_status()returnokexceptrequests.Timeout:returnuncertain# 查 biz_key 对应回执禁止立刻再 POST# 错误写法for _ in range(3): deliver_once(...)返回uncertain之后只查询。for循环重试会把已写入的那条再写一遍。拦截器白名单里如果包含这次 POST上面这段等于白写。对象域失败成员不在群、类型错误才进入补发讨论。补发是修正原因后的新一次出站通常应标记为补发避免被读成催促。节点掉线属于通道不可用恢复登录禁止在该态重试发送否则队列会被无效投递填满。把掉线和超时都登记成发送失败夜间重试器会把两类问题一起打爆。幂等键必须来自业务单号。随机 UUID 每次都是新的等于没做幂等。欢迎语、进群事件尤其容易被回调重放当天同一事件只出站一次。入站处理失败不要自动把出站再打一遍。客户端拦截器默认把超时当可重试错误多数 HTTP 库会把 5xx 与超时纳入重试白名单。对只读查询可接受对投递会复制会话记录。投递函数须自行维护成功、失败、不确定三态。白名单不要包括投递。进程内 Map 在重启后清空并发双提交只能靠存储层唯一约束挡住。两个 Web 实例抢同一通知内存锁帮不上忙。把读超时压到极短且下游实际已写入会话中应仍为一条。两个请求争用同一业务键亦应一条。只跑通一次连通文本给不出重试策略的安全性结论。上线前把「超时重试」从发送路径拿掉往往比再加一条欢迎规则更要紧。查看企业微信 API 文档https://doc.qiweapi.com/