个人微信实例和服务器进程不一样，它有真实的登录态，会掉线。客服机器人、订单提醒这类长期跑的业务，掉线意味着消息静默失败——接口报错你看日志能发现，实例掉了但没人盯，业务就断在那。

这篇给一套我们在用的三层保障：探活、自动重连、告警分层。接口以 Eyun 个人微信 API 文档为准，代码需校验后使用。

为什么必须自己探活

平台侧不会替你守着登录态。网络波动、手机端登录冲突、风控验证，都可能让实例掉线。你的发送队列还在跑，只是每一单都在失败。

所以实例健康检查要做成独立的巡检任务，而不是「发送失败了才想起来看」。

三层保障设计

第一层 探活:  定时调 /isOnline，读 data.isOnline 业务状态
第二层 重连:  异常时调 /reconnectWx，失败升级为人工告警
第三层 告警:  探活失败、重连失败、发送失败率，三个指标分别告警

只盯发送失败率是不够的：低峰期没有发送任务，掉线一小时都不会有任何报错，发现时已经丢了一批消息。

探活与重连代码

# 示例代码，需按官方文档校验
import requests, time

def check_and_recover(w_id):
    r = requests.post(f"{BASE_URL}/isOnline", json={"wId": w_id},
                      headers={"Authorization": f"Bearer {TOKEN}"}).json()
    # 坑点：code "1000" 只表示请求成功，在线与否要看 data.isOnline
    if r["code"] == "1000" and r["data"]["isOnline"]:
        return True

    # 掉线，先尝试自动重连
    rec = requests.post(f"{BASE_URL}/reconnectWx", json={"wId": w_id},
                        headers={"Authorization": f"Bearer {TOKEN}"}).json()
    if rec["code"] == "1000":
        time.sleep(5)
        return check_and_recover(w_id)   # 复查确认，不要盲信重连返回值

    alert_ops(f"实例 {w_id} 重连失败: {rec['message']}")   # 升级人工
    return False

# 每 60 秒巡检一次
while True:
    for wid in ALL_INSTANCES:
        check_and_recover(wid)
        time.sleep(2)
    time.sleep(60)

在线状态查询和断线重连接口的参数细节，分别见查询实例登录状态和断线重连两篇文档。

踩坑一：code 成功不等于在线

最常见的误判：拿到 "code": "1000" 就认为实例健康。实际上这个码只表示接口请求成功，业务状态在 data.isOnline 里，两个都要判。同理，判断失败不要写成「不等于 1001 就重试」——掉线的 wId 调群和资源类接口返回的是 "8000"，漏判会把重连逻辑跳过去。

Eyun 的错误排查文档把这些错误码按场景归了类，巡检任务上线前建议先对着它把分支逻辑过一遍。

踩坑二：重连成功但登录态是旧的

自动重连返回成功后不要立刻恢复业务。我们有一次重连返回成功，但消息收发实际没恢复，复查后才发现要等状态真正同步。现在重连后统一做一次复查确认（代码里的递归调用），确认 isOnline 为真才把实例放回发送池。

权衡：探活频率怎么定

频率	发现延迟	代价
10 秒	最快	请求量大，多数是无效轮询
60 秒	最多丢一分钟消息	我们的选择
5 分钟	低峰期丢消息风险高	只适合非关键业务

60 秒是业务损失和请求量的平衡点。比频率更重要的是告警可达性：告警通道本身就用微信，实例掉线时告警也发不出去——所以第一层告警一定走独立通道，短信或电话都行，别让监控和业务死在同一条路上。

收尾

实例运维没有黑科技，就是探活、重连、告警三件事做扎实。掉线不可避免，能控制在分钟级发现、分钟级恢复，业务就基本无感。完整的实例管理接口清单见Eyun开发文档，登录网络怎么选可以看Eyun 技术支持。你的实例巡检是怎么做的，评论区交流。