发货通知变成两条，客户会当成系统乱了，甚至怀疑多扣费。根因几乎总是：超时后以为失败又重试，而第一次其实已经发出去了。个人微信发送存在「第三类结果」——不确定成功也不确定失败。通知往往绑订单或合同，重复比聊天机器人双回更伤信任。「失败就重试」听起来负责，缺分类和占坑时反而是双发温床。先把失败分三类，再落发送占坑，最后按发送台账时间线处理客诉。

一、失败怎么分类

• 确定性失败（会话目标错、关系不存在、权限不足）：不原样重试；修数据后新开业务单。

• 不确定（超时、连接重置、网关无响应）：查发送台账；无成功凭证才有限退避，且同一业务单号。

• 设备异常（登录失效、设备离线）：暂停该 appId 出站队列，修复后再消费。

账号异常时不要对所有失败任务无差别重试。重试上限与退避配置化；超上限进死信告警。不要在 Webhook 或同步接口里直接重试发送——交给任务队列与发送台账。自动回复与主动通知若共用同一套重试逻辑且不换键空间，还会互相干扰。

二、发送占坑怎么写

send_notify(biz_id, type, appId, toWxid, content):
    if ledger.success(biz_id, type): return
    if not ledger.try_lock(biz_id, type): return
    result = postText(...)
    if definite_ok:   mark_success + 凭证
    elif definite_fail: mark_fail + 告警
    else: mark_unknown + 同 biz_id 有限重试

任务表持久化：业务单号、通知类型、appId、toWxid、尝试次数、最后错误、成功凭证。客服对账看凭证和时间线，别只看最后一次 HTTP 状态码。发送目标仍是 appId + toWxid（wxid_ / @chatroom），别用手填微信号顶替。出门幂等键用「业务单号 + 通知类型」，与自动回复键分离。台账建议至少有锁定、成功、失败、未知四态；锁定带过期，防止死锁。

三、联调验收几条就够

• 通道响应慢于客户端超时：本地记未知；重试前已有成功 → 禁止再发。

• 确定性失败：重试次数应为 0 或进人工。

• 同一业务单号并发发送：只一条 outbound。

• 产品若承诺「同订单同类型通知仅一次」，人工重发必须用新业务单号，并写进 SLA。

• 运营后台「重发」默认禁用，仅在失败且人工确认后生成新单号。

四、客诉双发时怎么查

先打开该订单的发送台账：两次成功的时间差、是否同一业务单号、中间有没有未知态。时间差极小且同一键，多半是占坑竞态或重试未查凭证；两个不同业务键，多半是人工点了两次或上游重复建单。修好后补回归：并发双 Worker 打同一单号，只允许一条成功。通知文案尽量带订单尾号，方便对齐是哪一次。策略写在任务层，通道只执行发送；路径与回执字段以官方文档为准。不确定就先查台账，再决定重不重试。

GeWe API 文档：GeWe API - GeWe API｜微信 API 开发文档