我们的值班群一周内收到过三类完全不同的"登录失败"：有的扫码就秒掉、有的取码一直失败、有的登录成功但半夜悄悄掉线。值班同学的处理全靠猜，猜错一次就要折腾一晚上。

后来我们把 Eyun 文档错误排查页的登录相关条目逐条过了一遍，发现五类错误的判断依据文档里都写得清清楚楚，整理成清单后值班处理时间从小时级降到分钟级。

五类错误对照清单

现象	文档原因	处理动作
登录后马上被踢（提示触发秒掉）	登录环境或账号状态异常	重新取码登录，按文档指引调整登录网络
提示保持网络助理运行，取码失败	用 Aid 登录但 Aid 程序没在运行	打开对应版本的 Aid 并全程保持运行
提示取码频繁	同一微信号一分钟内取码超过 6 次	等一分钟再取，避免连续重试
首次登录后 24 小时内掉线	属于文档说明的正常场景	传入原 wcId 重新登录
提示 wId 已注销或二维码失效	wId 填错或账号已掉线	查在线列表核对，重登换新 wId

清单的前三类发生在登录过程，后两类发生在登录之后，值班时先分辨"卡在哪一步"再对号入座。

原理：登录网络为什么重要

文档在接入注意事项里写了"登录网络要匹配账号常用地区"，提供平台代理、自定义代理、本地代理（Aid）三种方式。Aid 有 Windows、Android、Linux 三个版本，作用是让登录链路使用本地网络环境，Linux 节点文档建议放在账号常用城市。

我们踩过的坑在这里：登录时开着 Aid，成功后运维把 Aid 进程当闲置程序关了——很快掉线，团队误判是网络故障排查了两小时。Aid 不只是登录时的工具，是登录链路的一部分，文档要求"登录期间保持运行"，我们的理解是长期在线的实例就一直保持运行。

排查流程的固化

清单上手后，我们把判断流程固化成三步：

• 第一步看报错原文：Eyun 的失败原因写在响应 message 里，先读原文再动手

• 第二步对号入座：按上面的清单匹配类别，执行对应动作

• 第三步记录归档：每次失败记下现象与处理结果，清单随案例持续更新

第三步最有价值：清单上线一个月后，值班已经不需要翻文档，因为每类错误都被处理过并记录了。

踩坑：连续取码失败后的暴力重试

另一个真实教训：某次登录总提示取码频繁，值班同学写了个循环每五秒重试一次，结果一分钟 6 次的限制永远触发，卡死在循环里。文档写明同一微信号一分钟内取码超过 6 次就会触发限制——正确动作是停下来等，而不是更快地试。这类"重试对抗限频"的模式在登录环节全部无效，限频本身就是为拦截这种行为设计的。

权衡：值班自助排查还是提交支持

维度	值班自助	提交平台支持
响应速度	分钟级	看支持时段
覆盖场景	清单内的已知错误	清单外的新问题
成本	需要清单维护	需要问题描述质量

我们的分工：清单内的错误值班自助处理，清单外或清单动作无效的，带着报错原文、时间、实例状态提交 Eyun 平台支持——文档要求保留的诊断信息（脱敏后的 wId、响应 code、最近掉线原因）一并附上，问题定位快很多。

总结

登录失败不可怕，可怕的是拿网络故障的思路去处理账号与登录链路的问题。五类错误、一张清单、三步流程，加上"Aid 要保持运行"和"取码频繁要等待"两个纪律，登录环节的夜间告警基本消失。错误原文与处理方式以 Eyun 文档的排查页为准，清单外的新现象建议反馈给平台补进清单。