解决状态登录刷新问题

一、前言：用户为什么总在"关键时刻掉线"？

你是否遇到过这些场景？

• 用户填写了 10 分钟的表单，点击提交却跳转到登录页
• App 后台切换回来，提示"登录已过期"
• 客服正在处理工单，突然被强制登出

根本原因 ：登录态（Token/Session）过期，但系统未自动续期！

在用户体验至上的今天，"无感续期"已成为现代 Web 和移动端应用的标配。本文将带你彻底解决"状态登录刷新"问题，实现用户活跃时自动延长登录有效期，做到"用则不退，久不用则退"。

---

二、问题本质：固定过期 vs 滑动过期

策略	说明	用户体验
固定过期（Fixed TTL）	登录后 2 小时强制过期，无论是否操作	❌ 差（活跃用户也会被踢）
✅ 滑动过期（Sliding Expiration）	每次请求都延长有效期（如最后 30 分钟内有操作就续期）	✅ 好（活跃用户永不过期）

📌 目标 ：实现 滑动过期机制，让用户在持续使用时不被中断。

---

三、主流方案对比

方案	原理	优点	缺点
1. 前端定时刷新 Token	每隔 N 分钟调用 /refresh 接口	简单直观	空请求浪费资源；用户切后台仍刷新
2. 双 Token 机制（Access + Refresh）	Access Token 短期有效，Refresh Token 长期有效	安全性高	实现复杂；需管理两个 Token
✅ 3. 滑动过期（Redis 自动续期）	每次有效请求都延长 Redis 中 Token 的 TTL	无额外请求；精准续期	需拦截器支持

📌 推荐方案 ：方案 3（滑动过期） ------ 简洁、高效、用户体验最佳！

---

四、实战：基于 Redis 的滑动过期实现（Spring Boot）

1. 前提：已有 Token 登录体系

假设你已实现：

• 登录成功 → 生成 Token → 存入 Redis（TTL = 2 小时）
• 请求携带 Authorization: Bearer <token>
• 拦截器校验 Token 是否存在

若未实现，可参考前文《基于 Redis 实现短信登录》

---

2. 核心思路：在拦截器中自动续期

@Component
public class TokenAuthInterceptor implements HandlerInterceptor {

    @Autowired
    private StringRedisTemplate redisTemplate;

    private static final String TOKEN_PREFIX = "login:token:";
    private static final long MAX_EXPIRE_SECONDS = 2 * 3600; // 最大有效期：2小时
    private static final long RENEW_THRESHOLD = 30 * 60;     // 最后30分钟内才续期

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        
        String token = extractToken(request);
        if (token == null) {
            writeUnauthorized(response, "缺少认证凭证");
            return false;
        }

        String key = TOKEN_PREFIX + token;
        Boolean exists = redisTemplate.hasKey(key);
        if (!Boolean.TRUE.equals(exists)) {
            writeUnauthorized(response, "登录已过期，请重新登录");
            return false;
        }

        // ✅ 关键：滑动续期逻辑
        Long ttl = redisTemplate.getExpire(key, TimeUnit.SECONDS);
        if (ttl != null && ttl < RENEW_THRESHOLD) {
            // 距离过期不足30分钟，延长至最大有效期
            redisTemplate.expire(key, MAX_EXPIRE_SECONDS, TimeUnit.SECONDS);
            System.out.println("Token 续期成功，新TTL: " + MAX_EXPIRE_SECONDS + "s");
        }

        // 可选：将用户信息放入 ThreadLocal
        String userInfo = redisTemplate.opsForValue().get(key);
        UserContext.setCurrentUser(parseUser(userInfo));

        return true;
    }

    private String extractToken(HttpServletRequest request) {
        String authHeader = request.getHeader("Authorization");
        if (authHeader != null && authHeader.startsWith("Bearer ")) {
            return authHeader.substring(7);
        }
        return null;
    }

    // ... writeUnauthorized、parseUser 等方法省略
}

🔑 设计亮点：

• 仅在临近过期时续期，避免频繁写 Redis
• 每次有效请求都检查，确保活跃用户不掉线
• 无额外接口，对前端透明

---

3. 配置拦截器（放行登录等接口）

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Autowired
    private TokenAuthInterceptor tokenAuthInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(tokenAuthInterceptor)
                .addPathPatterns("/api/**")
                .excludePathPatterns(
                    "/login",
                    "/sms-login",
                    "/send-sms-code",
                    "/captcha",
                    "/public/**"
                );
    }
}

---

五、前端配合（可选优化）

虽然服务端已实现无感续期，但前端仍可做体验优化：

1. 记录 Token 过期时间

// 登录成功后
const expire = res.data.expire; // 时间戳
localStorage.setItem('token_expire', expire);

// 请求拦截器：提前提示
axios.interceptors.request.use(config => {
  const expire = localStorage.getItem('token_expire');
  if (expire && Date.now() > expire - 5 * 60 * 1000) {
    // 提前5分钟提示"即将过期"
    showWarning("您的登录即将过期，请及时保存工作");
  }
  return config;
});

💡 注意：前端时间不可信，最终以服务端 Redis TTL 为准！

---

六、安全与性能考量

⚠️ 安全风险：无限续期？

• 不会 ！因为：
  • 每次续期最多延长到 MAX_EXPIRE_SECONDS
  • 用户长时间不操作（>2小时），Token 仍会过期
  • 黑产无法通过刷请求无限续期（需合法 Token）

⚡ 性能影响：频繁 expire 操作？

• 极低 ！因为：
  • 仅当 TTL < 30分钟 时才执行 EXPIRE 命令
  • Redis 的 EXPIRE 是 O(1) 操作
  • 相比用户流失，这点开销微不足道

---

七、进阶：双 Token 机制（高安全场景）

若需更高安全性（如金融系统），可结合 Access Token + Refresh Token：

1. 登录返回：
   - access_token（有效期 15 分钟）
   - refresh_token（有效期 7 天）

2. access_token 过期后，前端用 refresh_token 换新 access_token

3. refresh_token 使用一次即失效（防重放）

但该方案复杂度高，普通业务推荐滑动过期即可。

---

八、避坑指南

❌ 坑 1：每次请求都无条件续期

后果 ：Redis 写压力大，且用户"永远不退出"
正解 ：只在临近过期时续期

❌ 坑 2：前端自行延长过期时间

风险 ：绕过服务端控制，造成安全漏洞
正解 ：所有过期逻辑由服务端 Redis 决定

❌ 坑 3：忘记放行登录接口

现象 ：登录请求被拦截器拦截，死循环
解决 ：务必 excludePathPatterns 放行 /login 等

---

九、结语

感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！