JeecgBoot项目中Token类型转换问题的分析与解决

问题背景

在JeecgBoot 3.7.3版本中，开发者在进行多租户功能测试时遇到了一个典型的Token类型转换异常问题。具体表现为系统在调用获取用户信息的接口时，Redis缓存中存储的用户对象类型与代码中预期的类型不匹配，导致类型转换失败。

问题现象

当访问/sys/user/getUserInfo接口时，系统尝试从Redis缓存中获取用户信息，但出现了java.lang.ClassCastException异常，提示无法将SysUser对象转换为LoginUser对象。通过Redis可视化工具检查发现，缓存中确实存储了两种不同类型的用户对象。

问题原因分析

1. 多环境切换导致缓存污染：开发者在不同分支（如sas、master或springboot3分支）之间切换时，没有及时清理Redis缓存，导致缓存中遗留了不同类型的用户对象。

2. 对象类型不一致：

   • 预期类型：LoginUser（系统登录用户信息封装类）
   • 实际存储类型：SysUser（系统用户实体类）

3. 缓存机制问题：JeecgBoot使用Redis缓存用户登录信息，不同分支或版本可能对用户信息的存储方式有差异，混用会导致类型不匹配。

解决方案

1. 立即解决方案：

   • 清理Redis中所有相关缓存数据
   • 重新登录系统，让系统重新生成正确的缓存数据

2. 长期预防措施：

   • 在不同分支切换时，养成清理缓存的习惯
   • 考虑为不同分支使用不同的Redis数据库或添加命名空间前缀
   • 在代码中添加类型检查逻辑，避免直接强制类型转换

技术实现细节

JeecgBoot的用户认证流程大致如下：

1. 用户登录成功后，系统会将用户信息封装为LoginUser对象
2. 生成Token作为key，将LoginUser对象存入Redis
3. 后续请求通过Token从Redis获取用户信息
4. 进行类型转换后使用用户数据

当缓存中存在不匹配的类型时，强制转换就会失败。正确的做法应该是在转换前进行类型检查，或者确保缓存数据的纯净性。

最佳实践建议

1. 开发环境管理：

   • 为每个开发分支配置独立的Redis实例或数据库
   • 在应用启动时自动清理旧缓存

2. 代码健壮性：

   Object userObj = redisUtil.get(loginUserKey);
   if(userObj instanceof LoginUser){
       loginUser = (LoginUser) userObj;
   } else {
       // 处理类型不匹配的情况
   }
   

3. 版本升级注意事项：

   • 当系统数据结构发生变化时，应当提供缓存迁移方案
   • 考虑使用版本化的缓存key，避免新旧版本冲突

总结

这个问题的本质是开发环境管理不当导致的缓存污染问题。在基于JeecgBoot进行开发时，特别是在多分支并行开发或版本升级场景下，开发者需要特别注意缓存一致性问题。通过建立规范的缓存管理流程和增强代码的健壮性，可以有效避免此类问题的发生。