通过即欢迎步骤看起来只有一次出站。生产里常见的是同一人两条欢迎或待验证阶段就投递失败被写成通道故障。事件次数与出站次数同样没有天然的一一对应。回调重放一次欢迎就加一条和「话术写了两句」不是一类问题。用待验证的人做接入演示失败会被当成通道不行。关系还没到对象域错误被说成接口坏了。通过事件可重放欢迎必须先落幂等回调重试与进程重启会让「通过」被处理两遍。事件表主键可用设备、对方标识、事件类型与自然日或直接用回调唯一消息 ID。已成功则返回。先发后记崩溃窗口内仍会双写。待验证不是好友出站属对象域错误。欢迎键要表达「谁对谁、哪一天、哪类事件」不要用随机流水defwelcome_key(app_id,friend_wxid,day):returnfwelcome:{app_id}:{friend_wxid}:{day}defon_friend_confirm(app_id,friend_wxid,day,db):keywelcome_key(app_id,friend_wxid,day)ifdb.exists(key):returndb.put(key)# 先占位再入队发送db.enqueue({appId:app_id,toWxid:friend_wxid,content:已通过欢迎})回调里不要直接requests.post发送。占位后再入队超时重推也打不进第二句。待验证不要进这个函数。好友确认类事件和聊天文本不是同一消费节奏。塞进同一个函数聊天高峰会把欢迎挤到几小时后变成莫名其句。欢迎应进自己的队列时效窗口写进配置。过了几小时是否还欢迎禁止默认全补。欢迎是任务不是回调函数里的同步 POST回调线程同步发送超时拖垮回调对端重推欢迎变两条。回调只写待欢迎任务号实例、对方 wxid、最终文案、业务键。发送进程按号限速新号间隔更长。业务键应表达「某号对某好友的通过欢迎」随机流水等于无幂等。掉线时任务停在通道不可用。通过已过去数小时是否仍欢迎用配置决定。词库按号隔离A 的欢迎出现在 B是客户端单例串号不是文案配错。投诉态零自动开口。未审核欢迎词不得入队。同一事件出站一次。重复 POST 同一回调会话仍一句。待验证不出站。刷新或网关重放不得变成第二条。这几条过了欢迎才算接到任务模型上而不是接到回调函数的一次成功返回上。查看个人微信 API 文档https://doc.geweapi.com/