内测群里最常见的一句抱怨，往往不是崩溃也不是闪退，而是「我昨天还能用，今天打开又要我登录」。开发第一反应是「网络问题吧」，测试也复现不出来，这件事就一直挂着。其实「掉登录」在客户端里是一类很具体的问题，拆开看只有三四种成因，每一种都能用固定步骤验证出来。

先分清三种「掉登录」

不同表现对应完全不同的原因，先把现象归类，再去查代码。

• 冷启动就要登录：登录态没有正确落盘，或者读取时机早于初始化。
• 用着用着跳登录页：Token 到期、被服务端判定失效，或被同账号在其他设备登录踢下线。
• 重装、换手机、清数据后要重登：属于预期行为，不算缺陷，但要在测试说明里写清楚。

把这三类混在一起讨论，容易把「设计如此」当成 bug 报，也容易把真缺陷当正常现象放过。

登录态到底存在哪

登录态通常一半在客户端、一半在服务端，两边任一环节不一致都会表现为「掉登录」。

• 客户端侧：iOS 常见 Keychain，安卓常见 SharedPreferences 或应用私有目录文件；卸载重装后的残留行为在两端并不相同。
• 服务端侧：会话记录、Token 有效期、单设备登录策略、改密后旧凭证是否作废。
• 中间层：网关或反向代理对请求头的改写，可能导致 Token 到达后端时已经失效。

内测阶段最有价值的信息不是「掉没掉」，而是「掉在哪一侧」。让客户端把当前 Token 的有效期、签发时间、登录来源打印出来，再对比服务端日志，定位通常只要十分钟。

内测要覆盖的六个场景

按顺序跑一遍，基本能覆盖绝大多数掉登录问题。

1. 强杀进程后重新打开，确认是否需要重新登录。
2. 放置到超过 Token 有效期或跨夜，再打开应用。
3. 同一账号在第二台设备登录，观察第一台是否被踢、提示是否清晰。
4. 修改密码后，用旧设备继续操作，确认旧凭证已失效。
5. 在应用内切换账号，检查上一个账号的本地数据是否残留。
6. 断网状态下启动，再恢复网络，观察是否自动恢复登录态。

第 5 项最容易被忽略：切换账号后若内存单例未重置，列表、购物车、草稿里可能出现上一个账号的数据，比单纯掉登录更难向用户解释。

把测试说明写清楚

内测用户不理解 Token、会话这些概念，只知道被要求重新登录了一次。在分发页面加一段说明，能省掉大量重复沟通。

• 什么情况下需要重新登录：换设备、改密码、超过有效期。
• 重新登录之后，本地数据是否还在。
• 遇到异常跳登录时，应该提供哪些信息：时间点、账号、机型、当时是否切换过网络。

包里保留一份可开关的调试日志，测试用户复现时能直接导出，比反复追问「你当时在干什么」有效得多。把新包上传到 虾分发 后，可以在应用说明里附上这段提示，测试用户扫码安装时就能看到。

常见问题

结语

「掉登录」并不玄学，它由登录态存储、Token 有效期、设备策略三件事共同决定。先把现象分类，再按六个场景跑一遍，多数问题在提测当天就能定位。与其在群里反复问「你刚才点了什么」，不如让包自己说清楚发生了什么。

建议 团队在提测单里固定加一行「登录态与账号切换已验证」，并注明本次使用的 Token 有效期设置，避免每次发版都靠口头确认。