线上最危险的操作不是掉线本身而是值班同学随手「再建一个号顶上」。半小时后你会看到一半消息失败、一半回错人、客服觉得有两个机器人在抢答。多设备与恢复路径见 GeWe 开放文档。真正炸掉的是什么不是微信是你的客户 → 主责设备映射customer_1024 → appIdA掉线 你新建 B只改了环境变量 DEFAULTB 旧队列还在打 A → 失败风暴 新回复走 B → 客户看到另一个号 回调仍按 A 的会话进线 → 路由精神分裂正确救火顺序立刻熔断停掉该appId的出站队列和重试避免失败打穿下游。恢复原号不新建按文档把原来的 A 拉回来扫码/登录恢复。新建是迁移不是故障默认动作。探针放行用 A 对一个测试好友/测试群发一条带时间戳的文本人眼确认后再放开队列。对账抽 50 条近 1 小时业务callback.appId是否等于send.appId。不一致的直接修映射。如果必须换号当且仅当你确认原号救不回来1. 冻结写入新进线进等待队列 2. 跑迁移脚本customer.primary_app_id A → B 3. 双写观察期回调用 B旧重试任务全部取消或改写 4. 观察期过了再删 A 相关配置禁止「改一个环境变量完事」。映射表不搬家业务库就是定时炸弹。防再犯代码里删掉DEFAULT_APP_ID启动时没有主责来源直接挂告警同一bizId回调设备 ≠ 发送设备值班手册第一行写掉线 → 恢复原号新建要走变更单号可以掉映射不能脏。脏了比掉线难修十倍。