企业微信机器人是长连接账号，掉线是日常而非异常：网络抖动、风控验证、被其他设备登录，都会让账号离线。掉线不可怕，可怕的是没人知道。这篇给一套三层守护设计：事件驱动、调用捕获、定时探测，并说明哪些情况能自动恢复、哪些必须交给人。

背景痛点

最常见的事故形态是：机器人跑了几周一直正常，某天半夜掉线，第二天客户消息积压了一整晚才发现。问题不在掉线本身，而在系统对"离线"这个状态既没有感知、也没有恢复策略——掉线处理必须是常驻机制，不是故障后的临时动作。

原理

掉线信号有两个来源。一是业务接口的返回：code 等于 -1 时，具体错误码在 message 竖线之前，比如 -11002 对应"已在其他设备上登录"。二是回调推送 instance.offline，错误码在请求体的 code 字段里，恢复后还有对应的 instance.online。

错误码决定恢复策略，这是整个设计的核心：-11001 可以自动重连；-11002 禁止自动重连，因为另一台设备正在登录，自动重连会两边互相顶号、反复掉线，正确动作是置为离线并提示用户；-2007 表示需要账号持有人重新扫码。

核心实现

三层守护各管一段（示例代码，需按官方文档校验）：

import time

def guard_loop(appid):
    # 示例代码，需按官方文档校验
    while True:
        resp = requests.post(
            f"{BASE_URL}/wx-api/api/personal/getInfo",
            headers={"Authorization": f"Bearer {CREDENTIAL}"},
            json={"appid": appid}, timeout=10,
        ).json()
        if resp.get("code") != 0:
            handle_offline(appid, resp.get("message", ""))  # 按 message 里的错误码分流
        time.sleep(300)   # 五分钟一轮，叠加 Webhook 事件作实时层

第一层是事件驱动：收到 instance.offline 立即按错误码分流，实时性最好。第二层是调用捕获：任何业务接口返回 -1 时解析 message 前的错误码，兜住事件推送延迟的情况。第三层是定时探测：定时调用只读的个人信息接口，网络或回调链路本身故障时也能发现账号异常。

三层最后都汇到同一个状态机：在线、重连中、离线待处理。-11001 触发断线重连接口，返回 code 0 只代表恢复流程已启动，真正在线要靠后续调用不再报错来确认。

踩坑

一、-11002 千万不要加自动重连，两边设备会互相顶号循环掉线，账号还可能被风控盯上。这属于必须人工决策的场景：要么换设备下线，要么由本人确认后重新扫码。

二、重连失败要退避：先确认登录网络代理还活着，间隔几十秒以上再试，连续失败就升级为重新扫码，别写成一秒一次的死循环。

三、重连接口返回成功不等于恢复在线，状态机里要有"重连中"这个中间态，以业务调用恢复正常为切换条件。

四、多账号场景给每个 appid 独立建状态机和守护任务，一个账号掉线不应影响其他账号的探测节奏。

总结

三层守护的本质是把"离线"从一个突发事件变成一个被管理的状态：事件保实时、捕获保兜底、探测保最终一致。恢复策略上严格分清自动与人工的边界，能自动的只留给 -11001。这篇基于Eyun 平台的企微接口整理，错误码表和重连接口的细节以官方开发文档为准。