AccessToken 过期的三种实践场景
假设AccessToken有效期 30 分钟，RefreshToken有效期 30 天。
场景 1：关闭网页，短时间内（如 5 分钟）又打开
- 表现：直接进入。
- 原理：前端从存储中读取
AccessToken发送请求。后端 Filter 发现 Token 签名正确且未过期（只过了 5 分钟），校验通过，用户无需重新登录。
场景 2：关闭网页，过了一天又打开
- 表现：页面闪烁一下（自动刷新），正常进入。
- 原理：
- 前端发送旧
AccessToken，后端返回401 Unauthorized。 - 前端 Axios 拦截器捕获 401，自动读取
RefreshToken调用刷新接口。 - 后端验证
RefreshToken有效，返回新AccessToken。 - 前端用新 Token 重新发起业务请求，用户感知不到重新登录的过程。
场景 3：打开网页并持续浏览超过 30 分钟
- 表现：无感续期。
- 原理：
- 在第 31 分钟时，发出的业务请求会因
AccessToken过期报 401。 - 前端拦截器发起“静默刷新”，获取新 Token 并继续完成刚才的操作。
- 用户在操作过程中几乎无察觉，流程与场景 2 类似。
深度解析：双 Token 机制下的无感刷新（Refresh Token）后端实现
1. 为什么要设计刷新令牌？
在 JWT 架构中，AccessToken通常设置较短的有效期（如 30 分钟），目的是降低泄露后的风险。但如果直接让用户每 30 分钟登录一次，体验会崩溃。
刷新令牌（RefreshToken）的存在，就是为了在不暴露用户账号密码的前提下，实现“令牌续期”，平衡安全与体验。
2. 后端核心实现流程
基于代码逻辑，后端处理refresh_token请求时遵循以下严谨步骤：
第一步：合法性与归属权校验
- 令牌存在性：首先通过字符串查询数据库/Redis，确认该
refreshToken是由系统颁发的。 - 客户端匹配：校验请求携带的
clientId是否与令牌记录中的编号一致。
安全要点：防止攻击者拿着 A 系统的刷新令牌去请求 B 系统的访问令牌（多租户/多应用场景下的关键防御）。
第二步：旧令牌的“彻底清理”（幂等性保证）
- 双写删除：在生成新令牌前，系统会查出该
refreshToken关联的所有旧accessToken。 - 同步清理：同时从MySQL和Redis中删除这些旧访问令牌。
目的：确保一个刷新令牌在同一时刻只对应一个有效的访问令牌，防止产生孤儿 Token 占用空间或造成安全隐患。
第三步：过期判定与自毁
- 逻辑检查：判断
refreshToken的expiresTime是否早于当前时间。 - 过期处理：一旦发现刷新令牌也过期了，后端会物理删除该刷新令牌，并抛出
UNAUTHORIZED异常。
结果：此时前端拦截器会引导用户跳转至登录页，完成“30天”后的重新认证。
第四步：新令牌的“以旧换新”
- 调用创建方法，生成全新的
accessToken，并重新存入缓存，返回给前端。
3. 核心代码
@Override@Transactional(rollbackFor=Exception.class)publicOAuth2AccessTokenDOrefreshAccessToken(StringrefreshToken,StringclientId){// 查询访问令牌OAuth2RefreshTokenDOrefreshTokenDO=oauth2RefreshTokenMapper.selectByRefreshToken(refreshToken);if(refreshTokenDO==null){throwexception0(GlobalErrorCodeConstants.BAD_REQUEST.getCode(),"无效的刷新令牌");}// 校验 Client 匹配OAuth2ClientDOclientDO=oauth2ClientService.validOAuthClientFromCache(clientId);if(ObjectUtil.notEqual(clientId,refreshTokenDO.getClientId())){throwexception0(GlobalErrorCodeConstants.BAD_REQUEST.getCode(),"刷新令牌的客户端编号不正确");}// 移除相关的访问令牌List<OAuth2AccessTokenDO>accessTokenDOs=oauth2AccessTokenMapper.selectListByRefreshToken(refreshToken);if(CollUtil.isNotEmpty(accessTokenDOs)){oauth2AccessTokenMapper.deleteByIds(convertSet(accessTokenDOs,OAuth2AccessTokenDO::getId));oauth2AccessTokenRedisDAO.deleteList(convertSet(accessTokenDOs,OAuth2AccessTokenDO::getAccessToken));}// 已过期的情况下，删除刷新令牌if(DateUtils.isExpired(refreshTokenDO.getExpiresTime())){oauth2RefreshTokenMapper.deleteById(refreshTokenDO.getId());throwexception0(GlobalErrorCodeConstants.UNAUTHORIZED.getCode(),"刷新令牌已过期");}// 创建访问令牌returncreateOAuth2AccessToken(refreshTokenDO,clientDO);}4. 技术亮点分析（面试/博客加分项）
1. 事务管理 (@Transactional)
在刷新过程中涉及“删旧”与“增新”两个数据库操作，必须保证原子性。如果新令牌生成失败，旧令牌的删除动作应该回滚。
2. 缓存与持久化双校验
- MySQL负责持久化存储，作为“真值来源”。
- Redis负责高性能校验，供
TokenAuthenticationFilter快速读取。
这种设计既保证了系统在高并发下的响应速度，又保证了数据不丢失。
3. 安全防范：令牌轮转 (Token Rotation)
虽然此处的refreshToken是复用的，但每次刷新都会注销掉之前所有的accessToken。这在一定程度上防止了令牌被截获后的长期滥用。
5. 总结：前端如何配合？
后端逻辑写得再好，也需要前端的**响应拦截器（Response Interceptor）**配合：
- 监控到业务接口返回401（AccessToken 过期）。
- 进入“静默重试”队列，调用后端的
refresh-token接口。 - 获取新 Token 后，自动替换本地存储，并原路重发刚才失败的业务请求。
