官网友情链接 wechatapi.net个人微信二次开发做到一定规模以后消息发送会逐渐从“调用一个发送接口”变成完整任务调度问题。最开始只有一个账号、每天几百条消息时收到客户消息后直接调用发送能力就可以。但多账号、微信群、自动回复、文件发送、AI 客服一起运行以后系统可能同时存在大量待发送任务。例如客户实时咨询需要立即回复销售任务计划发送跟进内容群机器人准备发送FAQ后台批量发送资料文件消息还要先准备资源。如果这些任务全部放在一个队列里按照先来先执行客户实时回复很容易被大量后台任务堵住。所以个人微信API接入以后消息发送需要单独设计调度队列。WechatApi 可以作为个人微信API接入层负责消息发送、账号、会话和文件能力。本地业务系统则负责队列优先级、账号配额、时效、幂等和失败补偿。一、发送队列为什么不能只有一个假设账号 A 正在执行 2000 条历史资料发送任务。客户突然发来“刚才那个问题还是不行。”自动回复任务排在第 2001 位。即使最终一分钟后回复成功业务体验也已经很差。所以实时客户消息和批任务应该物理或逻辑隔离。二、可以拆几类发送队列例如urgentrealtimenormalbatch。urgent投诉、重大故障、重点人工任务。realtime普通客户实时回复。normal销售普通跟进。batch历史任务、批量资料。调度器优先处理实时队列。三、一个具体例子系统同时有批量资料任务 5000 条实时私聊 30 条微信群FAQ 20 条投诉人工确认回复 2 条。合理执行顺序应该投诉 2私聊实时群聊实时批量资料慢速执行。而不是所有任务混在一个 FIFO 队列里。四、账号级队列也很重要即使任务类型分开如果账号 A 有大量任务也不能占用全部发送 Worker。每个账号可以设置max_concurrencyrate_limitburst_limit。这样账号 A 异常不会拖累 B、C。五、WechatApi 在这里的位置WechatApi 负责真正的发送能力。例如文本图片文件群消息。本地队列负责什么时候发哪个账号发是否还应该发。这两个职责分开后系统更稳定。六、发送任务一定要有截止时间客户实时回复可能 30 秒以后就价值下降。活动提醒活动开始后不再发送。批量资料时效宽松。所以每条发送任务最好有deadline_at。超过以后不再执行。七、发送前最终检查任务从创建到执行可能隔几分钟。执行前再判断会话是否人工接管客户是否免打扰原消息是否撤回账号是否正常任务是否取消规则版本是否仍有效。这是非常重要的安全门。八、消息内容要固定版本如果任务创建时使用回复模板 V3。排队期间模板更新到 V4。是否自动切换一般建议任务固定content_version。否则审核和执行内容可能不同。九、文件发送和文本发送分开文件任务通常需要上传获取资源发送。耗时比文本长。如果共用执行资源大文件会阻塞文本实时回复。所以文件发送可以独立队列。十、失败分类网络超时可以快速重试。账号异常暂停该账号任务。客户关系失效不再重试。文件失效重新准备文件或人工。错误分类决定补偿策略。十一、幂等发送任务最怕重复。任务第一次实际发送成功但状态写入失败。重试时不能再发一次。所以业务结果要有idempotency_key。例如source_message_id reply_rule_version。十二、人工发送也可以走统一队列吗即时人工回复可以优先级极高。仍然可以走发送服务获得日志幂等账号健康检查。但不能因为统一队列导致人工明显延迟。可以设置专用高优先级通道。十三、任务取消客户问题已经解决。旧AI回复还在排队。系统可以取消。状态cancelled。不要从数据库直接删任务。历史仍然知道发生过什么。十四、队列积压监控实时队列正常等待100ms。突然变成8秒。即使最终成功也说明系统已经有问题。可以监控queue_wait_timequeue_depthsend_latency。十五、账号恢复账号离线半小时。恢复后积压1000条任务。不能全部立即执行。先过滤过期人工已处理客户已取消。再渐进释放有效任务。十六、权限运营可以看自己任务。主管可以取消批任务。管理员能强制暂停账号发送。高风险操作需要审计。十七、数据看板发送任务总量实时队列平均等待失败率过期率取消率重复拦截。这些指标直接反映微信自动化健康度。十八、总结个人微信二次开发里的消息发送业务规模一大以后就不能再理解成“调一次接口”。WechatApi 可以提供个人微信消息发送能力但本地系统还需要通过实时队列、批量队列、账号级限流、deadline、执行前检查和幂等保证真正重要的客户消息优先执行。成熟的微信机器人不是“所有任务最终都发出去了”就算稳定而是实时客户不会被后台批任务堵住已经过期的内容不会补发重复任务不会重复触达。只有发送队列真正理解业务时效和优先级微信自动化才能长期保持自然、及时和可控。