前言：为什么企业权限必定要懂 LoginUser？

在所有的企业级后台系统中，“权限”始终是绕不开的核心。无论你在做的是 SaaS 平台、设备管理系统、能耗平台、ERP、智慧园区、数据中台、AI 平台……只要是后台系统，就离不开：

• 用户是谁？
• 他能做什么？
• 他不能做什么？
• 他有没有登录？登录多久？
• Token 什么时候过期？
• 怎么在每个接口识别当前登录者？

而在若依（RuoYi）框架中，解决这些问题的灵魂角色，就是今天的主角：

---

LoginUser —— 若依权限体系的“心脏”

只要你写若依项目，每一个接口里
SecurityUtils.getLoginUser() 背后，获取到的就是它！
只要你生成 Token，解析 Token，验证 Token，必定绕不过它！
只要你处理权限判断（Super Admin / Role / Menu / Button），必定要依赖它！

如果把若依比作一辆汽车：

• LoginUser = 汽车的发动机
• TokenService = 油箱
• SecurityUtils = 点火开关
• Interceptor = 发动机和轮子之间的传动轴

今天我们就把 LoginUser 拆得明清楚白，让你彻底吃透若依的权限体系！

---

第一章： LoginUser 是什么？它在哪？有什么用？

LoginUser 全路径如下：

com.ruoyi.framework.security.LoginUser

你可以把它理解成：

“登录用户的完整画像”

只要用户登录成功，这个 LoginUser 对象就会被存储到 Redis（或者 Sa-Token 的 Session），并在每次 Token 校验时重新装载回来。

它里面包含的信息超级丰富，例如：

✔ 用户基本信息
✔ 用户所属部门
✔ 用户的角色列表
✔ 菜单权限标识
✔ 按钮权限标识
✔ 登录时间、过期时间
✔ Token 字符串
✔ 浏览器 UA 等扩展数据

企业开发中所有与用户权限相关的逻辑，都从 LoginUser 出发！

---

第二章： LoginUser 的源码长什么样？逐行拆解讲清楚

下面是 LoginUser 的核心代码（不同版本略有差别，但本质一致）：

public class LoginUser implements UserDetails {
    private static final long serialVersionUID = 1L;

    private Long userId;          
    private Long deptId;          
    private Long loginTime;       
    private Long expireTime;      
    private String token;         
    private String ipaddr;        
    private String loginLocation; 
    private String browser;       
    private String os;            
    private Set<String> permissions;    
    private SysUser user;                
}

目前我将逐项拆开讲，让你完全理解每个字段的意义、使用方式、真实业务价值。

---

1. userId —— 用户唯一身份 ID

全系统通用身份标识。
在任何操作日志、审计系统、业务数据关联中都依赖它。

典型使用：

• 操作记录
• 数据权限过滤
• 接口权限校验

---

2. deptId —— 用户所在部门

用于多级组织架构与部门级权限隔离。

使用场景：

• 只能查看本部门数据
• 基于部门的审批流过滤
• 部门维度统计报表

---

3. loginTime / expireTime —— 登录有效期控制

结合 JWT 机制，实现动态续期。
防止用户被踢下线或长期占用登录状态。

---

4. token —— 身份凭证

每次调用接口时，你在 Header 中传的：

Authorization: Bearer XXXXXXX

依赖的就是 LoginUser 存储的 token。

---

5. ipaddr, browser, os, loginLocation

用于安全审计、风控策略，例如：

✔ 异地登录提醒
✔ 可疑设备登录拦截
✔ 登录日志记录
✔ 统计访问来源

---

6. permissions —— 菜单 & 按钮权限全集

这是角色系统的核心！

例如：

system:user:list
system:user:add
system:monitor:job:edit

Vue 前端会根据这个数组动态控制：

• 菜单显示/隐藏
• 按钮禁用/隐藏
• 路由是否可访问

几乎整个 RBAC 就依赖这个字段！

---

7. user —— SysUser 对象

把完整的业务侧用户信息装进去，让所有接口都能方便获取。

例如：

getLoginUser().getUser().getNickName()
getLoginUser().getUser().getAvatar()

---

第三章： LoginUser 是怎么被创建的？Token 怎么来的？

若依登录流程如下：

1. 前端提交登录参数
用户名 + 密码

2. LoginService 校验密码、查数据库

3. LoginService 创建 LoginUser 对象

4. TokenService 给 LoginUser 生成 Token

5. LoginUser + Token 存入 Redis

6. 返回 Token 给前端

7. 后续所有接口都带着 Token 来认证

☀️ 重点：LoginUser 是企业级权限体系的唯一载体！

---

第四章： 系统如何从 Token 中解析 LoginUser？

当你访问接口时，SecurityFilter 会进行：

1. 从 Header 提取 Token
2. 解密 Token 得到 userId
3. 去 Redis 查询 LoginUser
4. 放到 SecurityContextHolder

所以你在任意地方都可以这样取：

LoginUser loginUser = SecurityUtils.getLoginUser();

是不是超级丝滑？

---

第五章： LoginUser 在权限判断中的终极作用

菜单权限

Vue 根据 loginUser.permissions 动态渲染菜单

按钮权限

例如

v-hasPermi="['system:user:add']"

后端接口权限

@PreAuthorize("@ss.hasPermi('system:user:list')")

底层获取的也是 LoginUser → permissions

超级管理员判断

SecurityUtils.isAdmin()

---

第六章： 企业级开发中的典型使用案例（超级重大）

以下内容超级干货，尤其适合大型业务系统。

---

案例 1：操作日志记录

Long operatorId = SecurityUtils.getLoginUser().getUserId();
String operatorName = SecurityUtils.getLoginUser().getUser().getNickName();

用于记录“谁做了什么”。

---

案例 2：数据权限过滤

在 Mapper 层拼 SQL：

AND dept_id IN (SELECT dept_id FROM sys_dept WHERE find_in_set(dept_id, #{loginUser.deptId}))

---

案例 3：跨服务调用时传递用户身份

微服务场景下必备！

可以直接把 LoginUser 转换成 JSON 再传出去。

---

案例 4：构建审计中心

LoginUser 的 browser / os / ipaddr / loginLocation
可以直接作为风控参数输入规则引擎。

---

案例 5：动态权限刷新

当角色改动、菜单改动时，只需要：

重新生成 LoginUser → 刷新 Redis

系统权限立即生效！

---

第七章： 性能优化 & 架构扩展提议（企业级项目极其重大）

---

优化 1：LoginUser 中不要塞过多数据

大对象会导致 Redis 内存暴涨。
提议：不要加入与权限无关的大字段（如用户详情过长）。

---

优化 2：permissions 不要超过 10 万条

对大规模权限系统可以：
✔ 按角色缓存
✔ 按系统拆分权限
✔ 权限 Tree 结构扁平化

---

优化 3：Token 续期策略优化

若依内部有定时任务续期，提议调整：

✔ 移动端长登录
✔ 后台运营管理短登录

---

优化 4：适配 Sa-Token

若依新版支持 Sa-Token，LoginUser 可以直接作为 Session Object
让权限过程更优雅：

StpUtil.getSession().get("loginUser")

---

第八章：❓常见问题 Q&A（爆款文章必备）

---

❓ Q1：为什么 LoginUser 要序列化？

由于它要存 Redis，需要序列化、反序列化。

---

❓ Q2：为什么菜单权限和按钮权限都放在 permissions？

由于前端控制渲染，后端控制访问，两者都依赖同一套标识体系。

---

❓ Q3：登录后修改用户头像、昵称不生效？

由于 LoginUser 缓存未刷新。
解决：

重新写入 Redis 中的 LoginUser

---

❓ Q4：用户被禁用后登录仍可访问接口？

由于已有 Token 未失效。
解决：

踢出用户 session

---

第九章：✨ 写给架构师的进阶提议（超级关键）

---

提议 1：LoginUser 扩展租户字段

例如：

private Long tenantId;

可以实现多租户隔离（SaaS 必备）。

---

提议 2：扩展数据权限字段

例如：

private List<Long> deptScope;

可实现更复杂的数据权限矩阵。

---

提议 3：扩展登录设备信息

如：

• 设备唯一 ID
• App 版本号
• 信任设备标签

用于风控中心建设。

---

第十章： 总结：LoginUser 是整个若依生态的权限核心引擎

你需要记住一句话：

只要项目里需要识别当前用户，LoginUser 就是唯一来源。

它承担了：
✔ 用户信息载体
✔ 权限载体
✔ Token 关联对象
✔ 登录状态维护对象
✔ 审计数据来源

可以说，真正了解 LoginUser 的人，才算真正掌握了若依的权限体系！