移动端 App 遇到接口返回 Token Expired 时，应在网络层拦截 401 状态码，使用 Refresh Token 静默换取新 Access Token 后重试原请求。此方案适用于采用 OAuth2 或 JWT 双 Token 机制的场景，需注意防止刷新接口被并发调用。

快速处理思路

移动端自动刷新 Token 不需要命令行操作，核心在于客户端网络库的拦截器配置。建议在 OkHttp、Axios 或 Retrofit 拦截器中统一处理鉴权失败逻辑，避免在每个业务代码中重复判断。

if (response.code == 401 && errorMsg.contains("Token Expired")) {
    if (!isRefreshing) {
        isRefreshing = true;
        newToken = refreshAccessToken();
        retryQueue(newToken);
        isRefreshing = false;
    } else {
        addToQueue(originalRequest);
    }
}

为什么会这样

Access Token 设计为短有效期是为了降低泄露风险，Refresh Token 长有效期是为了维持用户登录状态。当 Access Token 过期时，服务端返回 401 或特定错误码，客户端需利用 Refresh Token 换取新的 Access Token 而不打扰用户。

这种双 Token 机制是 OAuth2 标准流程的常见变体，目的是平衡安全性与用户体验。如果只使用单 Token 且有效期过长，一旦泄露风险较高；如果有效期过短，用户频繁登录体验差。

分步处理

第一步：配置网络拦截器。在 HTTP 客户端初始化时添加响应拦截器，统一监听所有接口响应。检查响应状态码是否为 401 或业务码是否包含 Token Expired 标识。

第二步：实现刷新逻辑锁。定义一个布尔变量标记是否正在刷新，防止多个并发请求同时触发刷新接口，导致服务端压力增大或 Refresh Token 被多次使用失效。

第三步：维护请求队列。在刷新期间，将后续失败的请求暂存到队列中。刷新成功后，遍历队列，更新 Header 中的 Token 并重新发起请求。

第四步：处理刷新失败。如果 Refresh Token 也过期或无效，服务端通常返回特定错误。此时应清除本地存储的 Token 数据，跳转至登录页，避免无限重试循环。

怎么验证是否生效

查看客户端日志，确认捕获到 401 错误后是否触发了刷新接口调用。使用抓包工具观察网络请求，确认原失败请求在刷新后是否被重试，且重试请求的 Authorization Header 已更新为新 Token。

验证重试请求是否返回 200 状态码。模拟 Access Token 过期场景，手动修改本地存储的 Token 为过期值，启动 App 触发接口，观察是否无感知完成刷新。

常见坑

并发刷新问题：多个接口同时返回 401 时，如果没有锁机制，会并发调用多次刷新接口，可能导致 Refresh Token 被服务端判定为重复使用而失效。

无限重试循环：如果刷新接口本身也返回 401，拦截器逻辑需排除刷新接口自身，否则会导致死循环。务必在拦截器中判断当前请求路径是否为刷新接口。

时间同步问题：客户端本地时间与服务器时间偏差过大可能导致 Token 提前失效。建议以服务器返回的时间戳为准，或容忍一定的时间误差。

常见问题

Refresh Token 过期了怎么办？

Refresh Token 过期后无法自动刷新，必须引导用户重新登录。客户端接收到刷新失败响应后，应清除本地缓存并跳转登录页。

如何防止刷新接口被重复调用？

使用互斥锁或标志位。在第一个请求触发刷新时设置标志位，后续请求检测到标志位则加入等待队列，直到刷新完成。

单设备多标签页或多线程怎么处理？

确保刷新逻辑是线程安全的。在移动端通常通过单例网络客户端管理锁状态，Web 端可使用 localStorage 事件或共享 Worker 协调多标签页刷新。