最近又在技术群里看到有人问：“Java项目里的权限到底怎么做？”底下回复五花八门，有说直接上Spring Security的，有说抄一套若依的，也有说用Sa-Token更省事。说实话，权限模型这个东西我在Java后端摸爬滚打了五六年，从最早自己写过滤器硬编码判断，到后来老老实实按RBAC设计表结构，再到现在对比各种快速开发平台的权限模块，中间踩过的坑能写满一页A4纸。所以这篇笔记想把这件事完整梳理一遍：从基础RBAC的原理，到数据权限、行级权限这些衍生问题，再到Java生态里Spring Boot项目中的落地套路，以及当我们不想从零写权限时，快速开发平台到底该怎么选。
这篇文章适合谁看？我觉得三类人最需要：第一，刚接触Java后台开发、被“权限”两个字吓到的新人；第二，项目里权限越写越乱、想系统重构的老手；第三，正在做技术选型、纠结自己写还是用开源平台的团队负责人或者架构师。下面我尽量用大白话讲清楚，不堆八股文概念，把每个关键选择背后的理由也一并交代。
1. RBAC为什么能成为Java权限系统的默认答案
1.1 权限系统到底在解决哪三个问题
一上来先别急着看代码，先把“权限”拆清楚。我习惯把权限系统的问题拆成三个层次：你是谁（认证）、你能做什么（授权）、你能对哪些数据做（数据范围）。
这三者的关系有点像公司门禁。你是谁决定你能不能进大楼；你的职位角色决定你能进几楼几号办公室；而进了办公室之后，桌上哪份文件你能翻开看，还得看你的岗位职责是什么。认证环节通常由Spring Security、Sa-Token这类框架解决，授权和数据模型则需要我们自己设计，数据范围更是要结合具体业务单独定义。
很多新人只盯着第二个问题，把用户表、角色表、菜单表设计完就觉得大功告成。结果一上线就被业务方追着问：“为什么A部门的经理能看到B部门的订单数据？”这就是典型的第三个问题没考虑。所以你看，标题里说的“权限模型”，核心落点其实在授权和数据范围这两块，认证反而是相对现成的部分。
1.2 角色这个中间层：RBAC模型的核心设计
RBAC的全称是Role-Based Access Control，基于角色的访问控制。它的核心思路一句话就能说完：用户不直接关联权限，而是通过角色间接获得权限。
为什么中间要插一个角色？可以试想一下，系统里有10个用户、3个权限点。如果直接给用户分配权限，10乘以3就是30条关联记录。当用户数量到1000、权限点到200时，直接管理的复杂度会爆炸，而且每个人都可能配出不一样的权限组合，审计和调整都无从下手。
引入角色之后，所有同类用户共享一个角色，管理员只需要维护“角色—权限”关系，给用户分配角色即可。公司来了个新员工，拉进“运营”角色，菜单权限自动就有了；员工转岗，换个角色，权限自动收回。这个模型跟现实组织的管理逻辑完全吻合，所以业务方理解成本极低，这也是Java项目普遍选它的根本原因。
RBAC在学术上还分RBAC0、RBAC1、RBAC2等层级。RBAC0是基础模型，就是用户-角色-权限三元组；RBAC1加了角色继承，比如“运营总监”自动继承“运营专员”的所有权限；RBAC2加了职责分离约束，比如同一个人不能同时拥有“制单”和“审批”两个互斥角色。实际项目中，绝大多数需求用RBAC0加一点RBAC1就足够了，别一上来就把模型搞得太重。
1.3 一套可落地的RBAC表结构长什么样
理论说完看落地。网上流传的“五张表”指的就是：用户表、角色表、菜单（权限）表、用户-角色关联表、角色-菜单关联表。下面这套SQL是我在不同项目里反复调整后比较顺手的版本：
CREATE TABLE sys_user ( id BIGINT PRIMARY KEY COMMENT '用户ID', username VARCHAR(50) NOT NULL COMMENT '用户名', password VARCHAR(100) NOT NULL COMMENT '密码（BCrypt加密）', dept_id BIGINT COMMENT '所属部门', status TINYINT DEFAULT 1 COMMENT '状态：1正常 0停用', create_time DATETIME COMMENT '创建时间' ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY COMMENT '角色ID', role_code VARCHAR(50) NOT NULL COMMENT '角色编码', role_name VARCHAR(50) NOT NULL COMMENT '角色名称', data_scope TINYINT DEFAULT 1 COMMENT '数据范围：1全部 2本部门及以下 3本部门 4本人 5自定义', create_time DATETIME COMMENT '创建时间' ); CREATE TABLE sys_menu ( id BIGINT PRIMARY KEY COMMENT '菜单ID', parent_id BIGINT DEFAULT 0 COMMENT '父菜单ID', menu_name VARCHAR(50) COMMENT '菜单名称', perms VARCHAR(100) COMMENT '权限标识，如 system:user:list', menu_type TINYINT COMMENT '类型：1目录 2菜单 3按钮' ); CREATE TABLE sys_user_role ( user_id BIGINT COMMENT '用户ID', role_id BIGINT COMMENT '角色ID', PRIMARY KEY (user_id, role_id) ); CREATE TABLE sys_role_menu ( role_id BIGINT COMMENT '角色ID', menu_id BIGINT COMMENT '菜单ID', PRIMARY KEY (role_id, menu_id) );注意几个细节。第一，perms字段建议直接用“模块:功能:操作”的字符串格式，比如system:user:add代表“用户管理-新增用户”，比单纯存个菜单ID更好扩展，后端注解校验时直接比对字符串即可。第二，data_scope字段放角色表比放用户表更合理，因为同一个人的不同角色可能有不同数据范围，归角色管才不会乱。第三，菜单表里混着目录、菜单、按钮三类数据，靠menu_type区分，查询时按类型过滤就好。
提示：这张表只是基础。真正生产环境还要加部门表、操作日志表、角色-部门自定义数据范围表，但核心主线永远是这五张。
2. 从基础RBAC到复杂权限：角色继承、数据权限与行级控制
2.1 用户组与角色继承：组织架构复杂化后的第一步
基础RBAC用久了，第一个发现的问题是角色会爆炸。公司组织稍微复杂点，比如华东区销售、华东区销售经理、华南区销售、华南区销售经理，如果每个岗位都新建角色，权限一改就得同时改好几个角色，重复配置特别多。
这时候有两个常见解法：用户组和角色继承。
用户组解决的是“一批人批量获得一堆角色”的问题。比如“华东区销售组”里挂了50个账号，管理员给销售组分配角色时，组内所有用户自动生效，不用一个一个人点。用户组和角色的区别在于：角色表达的是“能力范围”，用户组表达的是“人员集合”，两者可以叠加使用。
角色继承解决的是“权限共性”问题，对应RBAC1。设计上可以让子角色持有父角色ID，比如“销售经理”继承“销售专员”的所有权限，再额外加上审批、查看报表的权限。查询当前用户权限时递归收集父角色权限即可。不过递归深度我建议控制在两层，最多三层，三层以上的权限级联会让排错变成噩梦，甚至出现“为什么这个人有这个权限”这种扯不清的情况。
2.2 数据权限：RBAC管不到“行”这一层
如果说角色权限回答的是“你能不能点这个菜单”，数据权限回答的就是“你点进去之后能看到哪些数据”。前者是接口和按钮级别，后者是SQL查询的数据行级别，也就是网上经常提到的“行级权限”。
最典型的业务场景就是部门分级管理。比如一份订单表，销售专员只能看自己名下的订单，销售经理能看整个部门的订单，运营总监能看全公司的订单。菜单权限大家都有，但查询结果的SQL条件完全不一样。
通常做法是在角色表上加一个data_scope字段，用数字字典表示范围：
| data_scope | 含义 | SQL追加条件示例 |
|---|---|---|
| 1 | 全部数据 | 不追加条件 |
| 2 | 本部门及以下部门 | dept_id IN (当前部门及子部门) |
| 3 | 本部门 | dept_id = 当前部门 |
| 4 | 本人 | create_by = 当前用户ID |
| 5 | 自定义 | 按用户自定义规则生成条件片段 |
这个字段的设计逻辑很直白：数据权限通常跟着角色走，换一个角色，数据范围就变一个层次。把data_scope放在角色表而不是用户表，也正好呼应了前面说的“角色表达能力范围”这件事。
2.3 字段级权限与按钮级权限的实现思路
除了行级控制，还有两个更细的维度容易被忽略。
按钮级权限说白了就是菜单表里menu_type=3那类按钮记录。前端拿到用户权限列表后，决定“新增”“删除”按钮是否渲染；后端接口再校验一次权限标识，防止有人绕过前端直接调接口。前端隐藏只是体验优化，后端校验才是安全底线。这个点我在后面踩坑部分还会重点讲。
字段级权限解决的是“同一个列表，A角色能看到手机号，B角色看不到”这类问题。实现上通常在注解里声明哪些字段需要脱敏或过滤，比如用户查询接口标注@FieldPermission({"mobile": "encrypt"})，后端在处理响应前自动按配置裁剪或加密字段。字段级权限对性能和代码侵入都有影响，一般只在用户信息、合同信息等敏感场景使用，不建议全系统铺开。
这两个维度补上之后，一套相对完整的权限模型才是：接口能不能调（接口/按钮权限）、数据能看到哪几行（行级数据权限）、数据里哪些列能看到（字段权限）。
3. Spring Boot + MyBatis下落地RBAC的完整套路
3.1 认证授权框架选型：Spring Security还是Sa-Token
在Java生态里落地RBAC，绕不开认证授权框架的选择。我接触最多的是Spring Security和Sa-Token，Shiro现在新项目已经很少有人选了，简单提一下即可。
| 维度 | Spring Security | Sa-Token | Shiro |
|---|---|---|---|
| 学习曲线 | 陡峭，概念多 | 平缓，上手快 | 平缓 |
| 功能完备度 | 极高，OAuth2/SAML等都能扩展 | 高，登录、踢人、单点都有 | 基础功能齐全 |
| 社区活跃度 | 极高，Spring官方维护 | 高，国内社区活跃 | 偏低 |
| 二次开发难度 | 过滤器链理解门槛高 | 注解+拦截器，直观 | 一般 |
| 典型场景 | 中大型项目、标准化企业架构 | 中小项目、敏捷交付 | 老项目维护 |
我的经验是：如果是全新项目、团队没人熟悉Spring Security，又想快速出活，Sa-Token非常友好，它的注解式鉴权和登录集成几乎零成本；如果团队有Spring Security基础，或者项目后续要接OAuth2、客户端资源服务等复杂场景，直接上Spring Security更稳。选型的核心不是谁更强大，而是团队能不能在两三周内真正驾驭它。
3.2 接口权限校验：注解 + 切面的实际写法
无论选哪个框架，接口级别的权限校验思路是通用的：先拿到当前登录用户的权限标识集合，再判断目标接口要求的权限标识是否在集合里。
用Spring Security时可以直接用@PreAuthorize：
@PreAuthorize("hasAuthority('system:user:add')") public void addUser(UserDTO dto) { // 新增用户逻辑 }如果不想绑定框架，也可以自定义注解加AOP切面：
@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequiresPermission { String value(); }@Aspect @Component public class PermissionAspect { @Before("@annotation(requiresPermission)") public void check(JoinPoint joinPoint, RequiresPermission requiresPermission) { String required = requiresPermission.value(); // 从当前登录上下文获取权限集合 Set<String> perms = SecurityUtils.getPermissions(); if (!perms.contains(required) && !perms.contains("*")) { throw new AccessDeniedException("无访问权限: " + required); } } }代码本身不复杂，但有个关键点容易漏：权限集合的获取时机。如果每次请求都查一次数据库，接口一多数据库压力会陡增。正确做法是登录成功时把权限集合写入Redis，key为用户ID；管理员调整角色权限时，主动删除对应用户的缓存key。后续请求从Redis读权限，既保证实时性，又不会反复压数据库。
3.3 MyBatis拦截器实现数据权限过滤
行级数据权限在MyBatis架构下最优雅的落地方式是拦截器。原理很简单：在执行查询SQL之前，根据当前用户的数据权限范围，动态往SQL里拼一个WHERE条件。
核心思路可以写成一个自定义拦截器，拦截StatementHandler的prepare方法：
@Intercepts({ @Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class}) }) public class DataScopeInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { // 1. 从上下文中获取当前用户的dataScope与部门ID // 2. 根据dataScope生成条件片段，如 dept_id IN (...) // 3. 通过BoundSql重新封装SQL，注意使用?占位参数，不要直接拼接字符串 // 4. 放行 return invocation.proceed(); } }具体实现时有两个坑。第一，SQL要正确注入到原有查询的WHERE位置，最简单的方式是用一个自定义注解标记需要数据权限的Mapper方法，拦截器只处理带注解的方法，避免所有查询都被动态改动，减少误伤。第二，条件片段里的部门ID集合要提前查出来作为参数传入，而不是在SQL里写子查询，否则大表场景下性能堪忧。
如果项目用的是MyBatis Plus，也可以参考内置的@DataScope注解方案。RuoYi等平台里面已经有现成封装，直接拿来改成本地版本，比自己从零写拦截器稳得多。
注意：数据权限是所有查询的公共底线，动手改拦截器之前，先把现有SQL的拼接位置梳理清楚，最好写几个核心场景的集成测试用例。
4. 快速开发平台的权限模块选型：从若依到芋道
4.1 主流开源平台的权限模块差异对比
标题里提到的“快速开发平台”，一般指集成了用户、角色、菜单、数据权限、代码生成器、后台管理界面的一整套脚手架。Java生态里这类平台非常多，我列几个有代表性的，重点看权限模块的差异。
| 平台 | 权限模型特点 | 技术栈 | 适合场景 |
|---|---|---|---|
| RuoYi（若依） | RBAC + 数据权限（部门+自定义） | Spring Boot + MyBatis + Vue2 | 中小后台、管理系统起步 |
| RuoYi-Vue-Plus | 增强版，支持多租户、数据权限更细 | Spring Boot 3 + Sa-Token + Vue3 | 需要多租户、快速交付的中小项目 |
| JeecgBoot | RBAC + 数据权限 + 在线报表 | Spring Boot + MyBatis Plus | 中后台+报表类项目 |
| yudao（芋道源码） | RBAC + 数据权限 + 多租户 + 工作流集成 | Spring Boot + MyBatis Plus + Vue3 | 企业级ToB/ToG项目 |
| JeeSite | RBAC + 数据权限 + 组织架构树 | Spring Boot + MyBatis | 传统企业管理软件 |
这里要特别提醒：不要只看star数量，要看权限模型是否贴近你的业务。比如RuoYi经典版的数据权限是经典的四模式，简单够用；RuoYi-Vue-Plus在多租户和行级过滤上更细致；JeecgBoot强在报表和工作流联动；芋道源码对多组织、多租户和企业工作流的支持更深入，适合定制化要求高的项目。拿一个简单平台去硬扛复杂权限需求，后面改起来会非常难受。
4.2 选型之前先想清楚你的权限复杂度
我的习惯是选型前先回答三个问题，三个问题想清楚，答案基本就出来了。
第一，项目是多租户还是单租户？如果是SaaS产品，租户隔离要做到哪一层？租户ID绑定在数据行上，还是只在登录用户层面隔离？RuoYi经典版默认没有完整的多租户能力，RuoYi-Vue-Plus和芋道则内置了，这一点差异非常大。
第二，数据权限的角色分级有多细？如果只是“管理员、普通用户”两档，随便一个平台的RBAC都够用；如果是五层组织架构加跨部门共享，那就必须仔细研究平台的data_scope是固定枚举还是可扩展的注解逻辑。
第三，权限变更频率高不高？高频变化的权限模型对缓存刷新、操作审计要求更高，需要平台有完整的缓存失效方案和操作日志；低频的话，简单的Session权限缓存就够了。
很多团队选型时只看界面好不好看、代码生成器强不强，把权限模型这个最核心的根基忽略了，这是我在不少项目里见过的最贵的一次学费。
4.3 自研权限模块的时间成本估算
聊完平台，肯定有人问：那我还不如自己写？这个问题的答案是：看你的核心业务是什么。
我按一个标准后台管理模块来估算自研成本。表结构设计和基础RBAC编写大约2到3天；登录认证接入2天；菜单权限和接口校验1到2天；数据权限拦截器实现2到3天；前端权限路由和按钮控制2到3天；操作日志、异常处理、缓存刷新这些加固工作3到5天。也就是说，一个比较完整的权限模块，一个人全职做，保守估计需要三到四周，而且这是没有踩大坑、一次设计到位的情况。
三到四周什么概念？对于大部分业务团队，这个时间足够用快速开发平台把整个管理后台搭出来，再把权限模块的核心需求定制完。当然，如果团队本身就打算沉淀一套统一的脚手架给多个项目复用，而且有专人长期维护，那自研完全值得。关键是自己写完之后，后面每个项目的权限需求变化都要有人持续接住，这个隐性成本往往被低估。
4.4 我推荐的选型思路
最后说说我个人的推荐思路，仅代表经验，不绝对。
如果是三五个人、两三个月内要交付的运营管理后台，直接选RuoYi-Vue-Plus这类开箱即用的平台，前端路由权限、后端数据权限、代码生成器都是现成的，把业务表建好就能开工。
如果是面向企业客户、权限和流程都很复杂的系统，优先考虑芋道这类企业级平台，或者从RuoYi-Vue版本fork出来做深度二次开发，把数据权限和多租户提前设计进去。
如果团队希望完全掌控代码，也不想被开源平台的代码风格束缚，那就按第三章的套路自研一个轻量版，前期控制好范围，不要把数据权限做成一个无限扩展的规则引擎。
无论选哪条路，权限模型的设计都不建议直接照抄网上的代码，因为每个业务的“数据边界”完全不一样，抄了表结构等于把别人的边界假设也抄进来了。
5. 我在权限模型落地过程中踩过的坑
5.1 角色变更后权限缓存不刷新
有一次开发环境里，测试人员反馈：给一个账号加了角色，刷新页面还是看不到新菜单。查数据库关联关系都正常，最后定位问题出在缓存。
我们在登录时把用户权限集合写入了Redis，但管理员在后台调整角色权限时，只改了数据库表，没有同步删除对应账号的缓存key。所有用户重新登录之前，权限就一直停留在旧状态。
解决思路有两个层面：一是角色权限变更时，主动清理涉及该角色的所有用户缓存，可以维护一张“角色与用户”的关系缓存索引；二是给权限缓存加一个相对短的过期时间，比如30分钟，作为兜底。生产环境两个方案都建议上，一个是实时性，一个是安全性。权限这种数据，宁可慢一点刷新，也不能让旧权限长期残留。
5.2 数据权限SQL拼接带来的注入风险
数据权限拦截器最容易出安全事故的地方是SQL拼接。我见过一个项目，为了防止跨部门查看数据，手写了数据权限过滤，但过滤条件是直接把前端传来的部门ID拼进SQL：
String sql = "SELECT * FROM orders WHERE dept_id IN (" + request.getParameter("deptIds") + ")";前端伪造一个deptIds参数传个1); DROP TABLE orders;--，整个表都保不住。数据权限过滤属于系统级安全控制，必须使用参数绑定，让MyBatis通过#{}处理，而不是${}直接拼。另外，自定义数据权限的SQL片段也要做白名单校验，只允许固定的表字段和操作符，不能开放任意表达式。
每次看到有人把安全控制代码写成可注入的字符串拼接，我都想强调一遍：权限模块是攻击者的重点目标，写的时候就要当它在真实对抗环境里跑。
5.3 前端隐藏按钮不等于后端安全
这个坑看起来简单，但我确实见过不止一次。前端根据权限列表判断是否显示“导出”按钮，没权限的人看不到按钮，于是大家觉得功能安全了。
直到有一天运营部门反馈，有人通过浏览器开发者工具构造了一个POST请求，绕过前端界面直接把全量订单导出成了Excel。原因就是导出接口只做了菜单路由权限校验，没做按钮级接口权限校验。按钮消失只影响用户体验和交互，接口是否可调必须由后端说了算。
正确姿势是：前端按钮按权限渲染，后端接口同时用@RequiresPermission("order:export")标注并校验，两个层面缺一不可。前端权限是为了让界面干净，后端权限是为了让数据安全。
5.4 第一版就上ABAC：过度设计的代价
最后一个坑有点反常识：权限模型设计得越“高级”，项目死得越快。
有个朋友的项目，一开始就想做一套万能权限系统，直接引用了ABAC（基于属性的访问控制），把用户属性、资源属性、环境条件全部建模，规则引擎都搭好了。结果上线后，业务方提的权限需求其实很简单，团队却花了大量时间在配规则和排查规则冲突上，一个“为什么这个人的权限变了”的排错周期能拖一整天。
我的建议是：第一版从标准RBAC开始，权限表只有用户、角色、菜单、关联关系，架构上留好扩展点。当真正出现“同一个用户在同一角色下、因上下文不同权限不同”的需求时，再局部引入ABAC或策略决策点。绝大多数业务系统，在很长一段时间里，RBAC加数据权限已经足够支撑。别为了技术的爽感，把简单问题做成复杂系统。
如果你正在做权限模块，我的实操建议是：先把基础RBAC的表结构理清楚，再根据业务把数据权限范围定义好，框架上用团队最熟悉的那一个，能选快速开发平台就别从零造。权限模型真正难的不是代码，而是把业务边界问清楚。想明白每一行数据在谁手里、谁批准、谁只能看不能改，表结构自然就出来了。这套思路我用了几年，项目基本都能平稳落地。也欢迎有不同经验的同行交流，毕竟权限设计的本质，是对业务规则理解的深度，而不是对框架的堆砌。
