简介面向若依RuoYi框架开发者的token过期时间配置源码包专注解决默认30分钟会话有效期过短、前后端超时配置不一致等问题。若依作为轻量级企业级快速开发平台其token机制直接关系到系统安全与会话稳定性本资源正是围绕这一关键点提供可直接参照的调整方案。压缩包共6个文件、约7KB包含后端application.yml、前端request.js及HTML说明文档等构成完整的配置修改与验证示例适合有一定Spring Boot和Vue基础、希望调整会话控制策略的研发人员。源码演示将expireTime设为120分钟、axios timeout设为7200000毫秒的前后端同步调整思路可避免因token过期时间不匹配导致的接口请求失败或重复登录同时附带refresh token刷新机制等扩展安全说明帮助读者深入理解若依框架的token管理原理规避配置过程中的常见坑点。资源虽小但结构清晰关键配置位置一目了然下载后可直接对照项目改动节省排查时间。已有191人学习浏览。 接手别人用若依框架做的项目第一件事基本都会遇到同一个问题token过期时间怎么改默认30分钟演示时够用一上生产环境就被客户吐槽“用着用着就被踢下线”。我前后用若依做过几个后台管理系统从简单的改配置到后面的自动续期、动态下线把token这块的源码翻了个底朝天。这篇文章就把我实际踩过的坑、验证过的方案一次性讲清楚按“先理解机制、再改配置、再上高级玩法”的顺序来无论是刚接触若依的新手还是打算深挖二次开发的都能直接照着操作。1. 搞清若依的token体系别被JWT两个字带偏1.1 双token结构access_token和refresh_token很多刚接触若依的人会以为“若依用的是JWT那token过期时间就是JWT的过期时间”。这个认知在早期单体版本里勉强成立但在目前主流的若依前后端分离版本RuoYi-Vue里实际情况完全是另一套逻辑。登录成功之后后端会返回两个token一个是access_token一个是refresh_token。这两个token本质上都是UUID字符串它们并不是真正的JWT。真正的JWT被放在了Redis里key是login_tokens:{uuid}value是一个存有用户信息和登录标识的LoginUser对象。也就是说access_token只是客户端拿着去Redis里换取用户身份的“钥匙”。这里就引出了一个非常重要的分布改了JWT的过期时间没用真正决定会话存活时长的是Redis里那条记录的过期时间。如果你只去改jwt配置里的expireTime最多影响的是token本身在理论上的失效时刻但Redis里的LoginUser可能早就被清掉了权限校验照样会失败。1.2 真正的业务凭证其实是login_user_key继续往下看源码会发现若依在生成token的时候做了一步关键操作从LoginUser里提取uuid拼成login_tokens:{uuid}再拿这个字符串去生成所谓的JWT。真正的JWT的payload里只存了一个login_user_key字段其他用户信息一概不放。这个设计初看有点绕细想之后反而觉得挺聪明。因为若依需要支持“动态踢人下线”“修改权限实时生效”如果把用户信息全塞进JWT那改完权限后旧token依然有效只能等token过期才能生效。但如果把用户信息放Redis每次请求都去查一次Redis改权限、踢人就能立刻生效。这是典型的用Redis换实时性的方案代价是多一次网络开销。所以在动手改token过期时间之前先记住这个结论时效控制的核心在Redis的key过期时间不在JWT本身。后面所有方案都是围绕这个结论展开的。2. 五分钟改完静态token过期时间的源码级操作2.1 核心配置项expireTime字段如果只是想让token有效期变成2小时最简单的操作是改application.yml里的配置token: # 令牌自定义标识 header: Authorization # 令牌密钥 secret: abcdefghijklmnopqrstuvwxyz # 令牌有效期默认30分钟 expireTime: 120这里expireTime的单位是分钟填120就是2小时。改完之后在TokenService的createToken方法里会通过expireTime计算出两个关键时间点// TokenService.java 中的核心逻辑 long expireTime getExpireTime(); // 对应配置文件里的值 LoginUser loginUser new LoginUser(); loginUser.setExpireTime(expireTime);真正把过期时间落到Redis的是这一句redisCache.setCacheObject(loginUserKey, loginUser, expireTime, TimeUnit.MINUTES);我建议改完配置后去TokenService里找到createToken方法顺手把expireTime打印出来看一眼确认配置真的生效了。因为有些项目会引入Nacos配置中心本地application.yml里改了没提交远程配置结果排查了半天发现读的是远端配置。2.2 autologin开关的作用解析除了expireTime若依还有一个容易被忽略的配置叫autologin在application.yml里通常长这样token: autologin: false这个配置直接影响登录接口里的一个分支判断。当autologin为true时登录成功后token的有效期会被单独设置成更长的时间一般用来做“记住我”这类功能为false时则统一走expireTime。如果你的项目里发现改了expireTime但某些用户的token依然很快失效大概率就是这里的问题。检查一下前端登录页面是否传了autologin参数以及后端ISysUserService里对应的方法是不是单独做了过期时长处理。我遇到过一版二开代码开发者在登录接口里硬编码了一个expireTime导致配置文件怎么改都不生效最后定位到是这行代码的问题。2.3 前端tokenTimeout的同步问题改完后端过期时间之后还有一个前端配置必须同步调整。若依前端的request.js里有一段tokenTimeout的判断逻辑用来在token即将过期时自动跳转登录页// request.js 中的关键配置 const tokenTimeout 1800000; // token过期时间单位毫秒默认30分钟如果后端过期时间改成2小时但前端这里还是30分钟就会出现一种很诡异的现场后端token明明还有效前端却频繁跳登录页用户刚登录完没操作几分钟就被踢回登录页。这个问题的排查思路很简单把后端expireTime和前端tokenTimeout调到一致即可。我习惯把后端改成小时级之后前端这个值也跟着放大同时写一个注释标明“此值必须与后端token.expireTime保持一致”避免后来接手的人改漏。3. 自动续期从30分钟固定过期到滑动过期3.1 固定过期时间的问题静态修改expireTime虽然简单但很快会碰到新的痛点用户正在填写一个长表单填到一半token过期了提交时直接跳到登录页填了半小时的内容全丢了。要么就只能把过期时间改成8小时甚至24小时但这又会带来新的安全风险——token一旦泄露攻击者可以长时间持有有效会话。更好的方案是“滑动过期”用户每次操作时刷新过期时间不操作一段时间后才真正过期。这就像健身房的会员卡每次你去刷卡都会从当天开始重新计算有效期一直不去才会失效。3.2 在verifyToken里做TTL刷新若依的请求校验链路是拦截器JwtAuthenticationTokenFilter拿到请求头的token解析出login_user_key再调用TokenService.getLoginUser去Redis里查LoginUser。所以只要在getLoginUser里每次成功查询后顺手刷新一次过期时间就能实现滑动续期。具体操作是在TokenService里找到getLoginUser方法在返回之前加一段刷新代码。不过我不建议直接改getLoginUser的逻辑因为有的接口比如定时任务回调、内部服务调用并不希望每次都被续期。更稳妥的做法是在verifyToken方法里处理// TokenService.java 中新增或调整的方法 public LoginUser verifyToken(String token) { LoginUser loginUser redisCache.getCacheObject(getLoginUserKey(token)); if (ObjectUtil.isNotNull(loginUser)) { // 每次有效请求都刷新过期时间实现滑动续期 refreshToken(loginUser); } return loginUser; } private void refreshToken(LoginUser loginUser) { loginUser.setExpireTime(getExpireTime()); redisCache.expire(getLoginUserKey(loginUser.getToken()), getExpireTime(), TimeUnit.MINUTES); }这里redisCache.expire是若依封装好的方法底层对应Redis的EXPIRE命令可以单独刷新key的过期时间而不修改value。关键踩坑点来了Redis里同一把锁、同一个缓存key的过期时间刷新必须确保使用的是同一个key字符串别在传参时把uuid拼错了否则会变成把一个新的空key设置过期时间原key纹丝不动。3.3 续期频率的安全取舍滑动续期虽然体验好也不能滥用。我在实际项目里见过一种错误做法在JwtAuthenticationTokenFilter里对每一个请求都无条件续期结果用户只要打开页面挂着不动前端每隔几秒发一个心跳请求token就永远不会过期。这相当于把过期时间变成了无效配置。我采用的折中方案是只在写操作、菜单/按钮权限校验等关键接口上续期普通GET请求不做续期。实现方式有两种一种是在verifyToken里加白名单判断另一种是前端的request.js里只对非GET请求携带一个“需要续期”的标记头。第一种更干净因为续期判断逻辑收口在后端不依赖前端配合。如果不想搞得太复杂还有一个简单版本在前端axios拦截器里只有在距离过期时间不足1/3时才主动调用一次刷新接口。这种方案相当于给token设置了一个“宽限期”但需要额外写刷新接口成本略高。我实测下来后端续期的方式更稳改动最小推荐优先尝试。4. 动态失效改密码后所有设备强制下线4.1 需求场景与原理真实项目中还有一个需求很常见用户修改密码后所有已登录的设备应该立即失效或者管理员封禁某个账号后这个账号正在使用的token要立刻作废。若依的token机制天然支持这个能力因为用户身份信息都存在Redis里只要把对应的key删掉token立刻变成无效。但问题在于若依的Redis缓存设计是login_tokens:{uuid}一个uuid对应一条记录。正常情况下一个用户可能同时在手机、电脑、平板三个设备登录会生成三个不同的uuid对应三条Redis记录。如果只知道userId没办法直接删除这个用户的所有token缓存。4.2 通过login_user_key实现全端下线若依官方提供了SysLoginService里的logout方法只能针对当前token做删除。要实现“所有设备强制下线”常见做法是把login_user_key的值设计成可索引的比如在生成LoginUser时额外存一个userId维度的key映射。我这里分享一个我实际用过的方案改动很小在用户登录成功时除了存login_tokens:{uuid}再维护一个login_user_ids:{userId}的Set集合里面存放这个用户当前有效的所有uuid。修改密码或封禁账号时遍历这个Set逐个删除login_tokens:{uuid}最后清掉Set。// 登录成功后维护 userId - uuid 集合 String userIdKey CacheConstants.LOGIN_USERID_KEY userId; redisCache.setCacheSet(userIdKey, loginUser.getToken()); redisCache.expire(userIdKey, expireTime, TimeUnit.MINUTES); // 强制下线遍历并删除该用户所有token public void kickOutUser(Long userId) { String userIdKey CacheConstants.LOGIN_USERID_KEY userId; SetObject tokens redisCache.getCacheSet(userIdKey); if (CollUtil.isNotEmpty(tokens)) { for (Object token : tokens) { redisCache.deleteObject(CacheConstants.LOGIN_TOKEN_KEY token); } redisCache.deleteObject(userIdKey); } }这套方案最值钱的点是理解了若依token体系的可控性——因为用户状态全部在Redis里所以“过期时间”“强制下线”“动态权限变更”这些都是随时可以操作的事。很多人在这一步才真正明白为什么若依不直接在JWT里塞用户信息。4.3 一个容易漏掉的续期场景还有一个场景我是被线上告警逼着才补上的用户在“记住我”模式下refresh_token本身的有效期很长但access_token过期后前端会尝试用refresh_token重新换取新的access_token。此时如果原来的login_user_key已经因为Redis过期被清理刷新接口会直接失败用户被踢下线。解决办法是让refresh_token在Redis中的过期时间比access_token更长。从源码上看若依默认的refresh_token生成逻辑和access_token共用一套过期时间这在实际生产中确实不够用。我建议二次开发时给刷新令牌单独设置一个更长的过期时间保证在会话持续活跃期间刷新链路不会因为底层缓存被清而断掉。5. 常见问题排查与避坑指南5.1 一个典型的坑expireTime改得很长但Redis内存被打满把expireTime从30分钟改成2小时之后有朋友反馈说Redis内存直线上升排查后发现是登录接口在极端情况下会反复创建新的LoginUser而旧记录要等2小时才会被Redis清理。这个问题不算token配置本身的问题但在高并发登录场景下会放大。我给出的建议是不要无脑把expireTime调大先确认项目里是否有类似的短时高频登录场景。如果有考虑引入单用户单会话模式后登录的挤掉先登录的或者在登录前先清理该用户已有的旧token。也可以利用Redis的maxmemory-policy allkeys-lru策略但这种方式不可控不推荐生产环境依赖。5.2 坑前端tokenTimeout没同步大屏/定时任务白屏若依经常被拿来做管理后台而管理后台里常有大屏展示或者定时刷新数据的页面。这些页面通常是页面加载时获取一次token然后通过setInterval定时拉数据。如果后端过期时间比前端tokenTimeout短就会出现大屏挂在那里定时请求一直401但页面既不跳登录页也不报错看起来就像“白屏了”。处理方法是把大屏页面的数据接口排除在token过期校验之外或者让大屏页面在收到401时静默刷新token并重放请求。前者操作简单后者体验好我倾向于后者。具体实现可以封装一个refreshTokenAndRetry函数在axios响应拦截器里判断401后重新获取token再把原请求重发一次。5.3 坑时钟偏移导致“登录已过期”这个坑比较隐蔽。若依在TokenService里会校验“最后操作时间”如果发现当前时间与最后操作时间的差值超过了设定的过期时间会主动从Redis里删除LoginUser。这个判断依赖服务器时间如果服务器时钟不准或者前端和后端不在一个时区可能才登录没多久就被判定为过期。排查方式是去看服务器时间是否与标准时间同步如果有偏差先校正时间再观察。另外如果项目部署在容器里注意宿主机与容器的时间同步问题。这个坑排查起来很费劲但一旦出现会让很多人误以为是代码写错了。5.4 安全建议定期更新token密钥最后说一个和过期时间同样重要的点application.yml里的token.secret是JWT签名密钥。很多项目上线后从头到尾不换这个密钥一旦源码泄露攻击者就能伪造任意token。建议在项目启动时通过环境变量注入密钥而不是硬编码在配置文件里并且定期轮换。轮换时机最好选在低峰期轮换后所有旧token会失效需要用户重新登录。这里的“重新登录”如果放在白天高峰期会让大量在线用户瞬间掉线体验很差。我踩过这个坑后来学乖了每次轮换都提前发公告选择凌晨执行。写在最后的一点个人经验若依的token机制虽然看起来绕但拆开之后其实就两个核心Redis管状态JWT管标识。弄懂了这一点改过期时间、做自动续期、做强制下线所有需求都变得清晰起来。从我这些年的实践来看token过期策略没有完美的配置只有适合业务的方案。B端后台管理系统适合滑动续期C端App适合长有效期refresh_token高安全场景则适合短有效期频繁校验。我最后再分享一个小技巧改完token相关逻辑后别只在浏览器里测用curl带token打几个接口再从Redis里手动EXPIRE一下key验证动态失效是否生效。这套验证流程我第一次走的时候还真抓到了两个漏判的分支。本文还有配套的精品资源点击获取
)
)
