Webhook 配好了，第一条能进自己的服务。处理函数里同步查库、调模型、再调 postText，整段十几秒。通道按超时重试。你后半段才 200，通道当失败，又推一次。newMsgId 若没做去重，同一句客户消息会出站两次。个人微信 API 二次开发里，这常被写成机器人连发。连发根子经常在入口时钟，不在词表。

「收到回调」不是「当场把客服做完」。

入口只确认，确认要快

通道要尽快知道你收到了。业务要最终那句回复正确。时钟不同。超时再送时，如果你已经回复过，就会再回复。入口只做：读 isSelf、校验、按 appid + newMsgId 去重、入队、返回。词表和发送放消费者。

没有 newMsgId 不要上自动回复。用正文当键，两句真实「你好」会被合并。appid 必须进键，多号时只拿消息 ID 会串。

def on_webhook(event, db, q):
    if event.get("isSelf") is True:
        return {"ok": True}
    app_id = event.get("appid") or event.get("appId")
    nid = event.get("newMsgId")
    if not app_id or nid is None:
        return {"ok": False, "reason": "missing_id"}
    key = f"{app_id}:{nid}"
    if not db.try_insert("cb:" + key):
        return {"ok": True}
    try:
        q.put(event)
    except Exception:
        db.delete("cb:" + key)
        raise
    return {"ok": True}

入队失败要删去重键，否则消息既没进队又再也进不来。不要在这个函数里调发送。发送超时叠在回调超时上，窗口必破。返回形态以文档为准。

重放是常态

网关、进程重启、对方超时，同一 newMsgId 会再来。消费者还要用业务键防双气泡。入口防重复计算，业务键防重复会话。少一层，另一层会被打穿。msgType 不是 TEXT 的，第一期不要在回调里同步下载附件。

验收：入口故意超过超时阈值，重推后出站仍一条；入口快速返回、消费者延迟发送，仍一条；丢掉 newMsgId 应拒绝而不是改用正文。这组不过就接模型，超时只会更长。个人微信机器人连发，先查这组，再改话术。

查看个人微信 API 文档：
https://doc.geweapi.com/