尧图网页设计 
1. 权限系统的本质你不是在写代码是在定规则做了这么多年Java后端我越来越觉得权限模型是绝大多数业务系统的“地基中的地基”。你可能有过这种经历项目快上线了产品突然说用户A能看到部门B的数据但用户C不行或者外部审计要求所有操作留痕你只能临时在Controller里塞一堆if判断。这些问题的根源往往不是代码写得差而是最开始就没把权限模型想清楚。权限系统到底解决什么问题用一句话概括它回答了“谁”能对“什么资源”做“什么操作”这个三元问题。RBACRole-Based Access Control基于角色的访问控制是目前最主流、也最适合绝大多数业务场景的答案。它的核心思想很朴素——把“权限”不直接绑在用户身上而是绑在“角色”上用户通过拥有角色来获得权限。为什么这个抽象如此重要因为现实世界中人和角色的关系是动态变化的。一个员工从销售岗调到市场岗如果权限直接绑在用户身上你就得一条条改这个用户的权限配置而有了角色这层“中间商”你只需要把他从“销售角色”挪到“市场角色”就行。这个“中间商”就是RBAC最大的价值——解耦。这篇文章不只是讲理论我会把RBAC从最基础的模型讲透再延伸到行级权限、数据范围这类实战中绕不开的难点最后结合我在多个项目中做权限模块的经验聊聊怎么评估一个快速开发平台的权限功能是否靠谱。面向的读者是Java后端开发、架构师以及正在选型快速开发平台的技术负责人。2. RBAC模型全拆解从只能应付demo到能上线生产2.1 基础RBACRBAC0到底包含哪些要素RBAC0是核心模型所有其他RBAC变体都是在这个骨架上长出来的。它定义了四类实体用户User、角色Role、权限Permission、会话Session。权限再细化一点可以拆成“操作”Operation和“资源”Resource两个维度。这个拆分非常重要很多初学者设计表结构时只建了一张“权限表”里面放个权限名称字符串结果后续根本没法做细粒度控制。我把权限拆成“操作资源”之后表结构通常是这样设计的用户表sys_user角色表sys_role用户角色关联表sys_user_role权限表sys_permission字段包括resource_type、resource_id、operation角色权限关联表sys_role_permission这套五张表的结构是RBAC0的经典落地方案。权限表里的operation我习惯用RESTful风格的动作来描述比如“查看用户列表”对应GET:/api/users而resource_id则指向具体的资源标识。这样设计的好处是以后想加细粒度限制不需要改表结构在既有框架上扩展就行。2.2 角色继承RBAC1和责任分离RBAC2复杂组织架构的救星现实中公司组织架构往往超过三层。集团有集团总裁分公司有分公司总经理部门有部门经理。如果每个层级都建一套独立的角色角色数量会爆炸而且职责边界会变得模糊。这时候就要用RBAC1的角色继承能力。角色继承在实现上我最推荐“树形结构”——子角色继承父角色的所有权限并在此之上增加自己的特有权限。举个例子“分公司总经理”继承“部门经理”的全部权限额外拥有跨部门审批的权限。在代码层面查询用户权限时要递归收集父角色的权限集合这里记得做去重和缓存不然沙雕递归性能会很难看。RBAC2则引入了约束概念包括互斥角色比如一个用户不能同时是“审批人”和“申请人”这在流程引擎场景巨常见和基数约束一个角色最多只能有XX个用户。我做过一个信贷审批系统就强制要求“初审员”和“终审员”不能是同一人这就是典型的静态职责分离。2.3 数据范围从功能权限到行级权限的天花板基础RBAC解决了“能不能访问这个菜单、能不能点这个按钮”的问题。但业务一旦跑起来你会发现真正的魔鬼藏在“能看到哪些数据”里。同样拥有“查看订单”权限的销售A和销售BA应该只能看到自己的订单B如果是个销售主管他应该能看到整个团队成员的订单。这就是行级权限Data Scope。业界最主流的方案是“部门数据范围”“用户数据范围”组合本人数据仅本人创建的数据本部门数据部门内所有成员的数据本部门及以下部门数据递归包含子部门全部数据不过滤常用于管理员角色的超级权限实现方案上我强烈建议在MyBatis层面做拦截器统一拼接数据权限SQL而不是在业务代码里手动加条件。手动加的问题是——你永远不知道哪个开发忘了加。我在项目里实现过基于注解DataScope的切面拦截在Mapper执行前动态注入SQL片段。核心思路是解析当前登录用户的数据范围类型然后生成对应的WHERE条件比如WHERE creator_id #{userId}或WHERE dept_id IN (...)。这个方案还有两个升级版玩法一是把数据范围本身也做成“角色权限的一部分”即角色表里加data_scope字段这样可以实现“同一个角色不同数据范围”的灵活配置二是结合机构树把部门表做成ancestors字段存储全路径这样查“本部门及以下部门”时就只需要一条LIKE查询性能远好于递归遍历。3. RBAC的常见变体与踩坑别一上来就搞最复杂的3.1 用户组User Group模型当角色数量失控时很多系统跑着跑着角色数量就失控了。一个电商后台运营一个角色、运营二组一个角色、数据专员一个角色、数据分析师一个角色……角色表越来越臃肿角色分配管理越来越痛苦。这时候引入用户组User Group是一个成熟的选择用户组本身就代表一批用户的集合你可以给组授权也可以给组里的某个用户额外授权。我见过不少优秀的开源项目比如若依框架就把用户组玩成了“岗位”的概念。用户组和角色的核心区别在于角色代表“权限集合”用户组代表“组织身份”。授权时两者可以同时生效取并集。这能极大降低权限配置的冗余度。3.2 ABAC什么时候值得上“属性权限控制”RBAC的局限在于权限模型的描述粒度是“角色”但真实世界有些规则无法简单用角色表达。比如“如果当前是工作日上午9点到12点允许提交加急订单”“只有当订单金额小于5000元时一线客服可以直接退款”——这种基于时间、金额、上下文等属性的动态决策RBAC表达起来很痛苦。这就是**ABACAttribute-Based Access Control基于属性的访问控制**的用武之地。ABAC的策略通常用规则引擎来管理Java生态里比较成熟的是Spring Security的注解式表达式配合PreAuthorize高度灵活但调试困难复杂规则容易变成“黑盒”。我的建议是90%的业务场景用RBAC就够了只有那些真正需要实时决策比如风控、审批流的子模块再引入ABAC并且把规则集中管理、加上完善的单元测试否则后期维护会非常酸爽。3.3 项目实战中的角色权限设计checklist跑过几个大型项目以后我总结了一份角色权限设计时需要自查的清单每次动权限模块都对着过一遍能省掉不少返工角色是否支持树形继承长期演进必备数据范围是否内置为权限维度这个是业务刚需不是可选项权限变更是否实时生效还是必须重新登录需求要提前定清楚是否存在互斥角色尤其涉及审批流、合规审计的场景是否预留了“特殊授权”通道比如临时给某个用户开某个接口的白名单这在运维场景很常见权限操作的日志是否完整谁在什么时候改了什么角色的权限——如果公司有审计要求这块是刚需4. Java权限框架的技术选型Spring Security和Shiro的取舍4.1 Spring Security体系庞大但值得长期投资Spring Security在Spring Boot项目中几乎是事实标准。它的核心链路是过滤器链Filter Chain——每个请求依次经过一系列过滤器实现认证、授权、会话管理等能力。这个模型在单体应用里很清晰在微服务架构下还能无缝集成OAuth2、JWT、OIDC。Spring Security的授权模型天然支持RBAC——GrantedAuthority就是角色/权限的抽象。你可以通过hasRole(ADMIN)、hasAuthority(user:list)等方式做细粒度控制。方法级别的安全还能用PreAuthorize做基于SpEL表达式的ABAC扩展。它的缺点也很明显学习曲线陡峭、配置繁琐。网上流传着“Spring Security是面试造火箭、工作拧螺丝”的说法有一定道理。但我的亲身感受是一旦项目上线、业务复杂起来Spring Security的扩展性优势就会迅速碾压Shiro。如果你做的是面向未来的中大型项目投资Spring Security是值得的。4.2 Apache Shiro轻量、易上手但边界明确Shiro最大的标签是“简单、直观”API设计非常友好。它的核心概念是Subject、SecurityManager、Realm。你只需要实现一个Realm告诉Shiro如何根据用户名查到用户和角色剩下的活儿它就自己干了。如果你的项目是中小型单体应用、权限模型就是“用户-角色-权限”三板斧Shiro完全够用。但Shiro有个硬伤它在Web安全防护比如CSRF、CORS、Session Fixation方面远没有Spring Security完善。而且随着Spring Security在Spring Boot里的开箱即用程度不断提升Shiro的“简单”优势也在缩小。选型建议表直接放这里维度Spring SecurityApache Shiro学习曲线陡峭平缓Spring Boot集成度原生级需额外适配Web安全防护完善较弱OAuth2/JWT支持原生支持需手写适合场景中大型、复杂授权、微服务中小型、简单RBAC社区活跃度极高一般4.3 轻量级权限框架到底怎么选一个自研小组件的思路很多团队最终发现无论是Spring Security还是Shiro在接入“行级权限”“按钮级权限”等业务需求时都需要大量自定义开发。既然如此我自己在项目中实践过一套轻量级权限组件思路值得分享认证直接基于JWT Token拦截器解析token、装载上下文授权基于注解拦截器实现RBAC校验支持类级别、方法级别的权限点配置数据权限在MyBatis层统一处理通过线程上下文获取当前用户的数据范围在SQL执行阶段动态改写这个轻量组件的核心价值不是“造轮子”而是让权限逻辑完全服务于业务模型而不是去迁就框架的限制。当然自研的前提是你对权限模型理解得足够深否则不如直接用Spring Security的扩展点改造。5. Spring Boot MyBatis下的RBAC落地实现手把手搭一套核心逻辑5.1 数据库建表与核心字段设计假设你的业务系统已经有用户表和部门表权限模型部分我建议直接建这五张表CREATE TABLE sys_role ( id BIGINT PRIMARY KEY, role_code VARCHAR(50) NOT NULL UNIQUE, role_name VARCHAR(100) NOT NULL, data_scope TINYINT NOT NULL DEFAULT 2 COMMENT 1全部 2本部门 3本部门及以下 4仅本人, status TINYINT DEFAULT 1, create_time DATETIME, update_time DATETIME ); CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY, perm_code VARCHAR(100) NOT NULL COMMENT 如 user:list, perm_name VARCHAR(100), resource_type VARCHAR(50) COMMENT menu/button/api, parent_id BIGINT DEFAULT 0 ); CREATE TABLE sys_role_permission ( role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, PRIMARY KEY (role_id, permission_id) ); CREATE TABLE sys_user_role ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id) );这里有个细节data_scope我放在角色表而不是用户表意味着“同一个用户如果拥有多个角色取数据范围最大的那个”。这是业务上最常见的规则但实现时一定要在代码里写清楚优先级否则后面排查数据可见性问题会想撞墙。5.2 核心鉴权拦截器逻辑简单细节魔鬼登录拦截器里做三件事解析Token、从缓存中加载用户权限、写入上下文ThreadLocal。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); Long userId JwtUtil.parseToken(token); // 从缓存取用户角色和权限集合避免每次请求都查库 SetString permissions permissionCache.get(userId); UserContext.set(userId, permissions); return true; } Override public void afterCompletion(...) { // 防内存泄漏一定要清理ThreadLocal UserContext.clear(); } }注意afterCompletion里的清理动作——我之前接过一个别人留下的项目ThreadLocal没清理Tomcat线程池复用后权限串号排查了一整天。这种问题不会立刻报错但会在流量上来后随缘出现属于最恶心的线上故障之一。5.3 数据权限动态SQL的实现思路行级权限的核心代码在MyBatis拦截器里。下面给出核心逻辑的伪代码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 { StatementHandler statementHandler (StatementHandler) invocation.getTarget(); // 获取原始SQL String originalSql statementHandler.getBoundSql().getSql(); // 根据当前用户的数据范围重写SQL String newSql rewriteSql(originalSql); // 通过反射修改boundSql.sql字段 Field field BoundSql.class.getDeclaredField(sql); field.setAccessible(true); field.set(statementHandler.getBoundSql(), newSql); return invocation.proceed(); } }这里忠告一句拦截器重写SQL是把双刃剑。它确实能帮你实现“无侵入”的数据过滤但SQL的规则复杂度一上来调试就是地狱。所以务必在开发环境打开MyBatis的SQL日志配合单元测试覆盖“不同数据范围下的SQL结果”。线上权限出错大概率就是这一步的问题提前把测试写稳比啥都强。6. 快速开发平台选型指南权限能力是第一硬指标6.1 为什么权限模型是选型的核心标准这些年我接触过很多快速开发平台包括若依RuoYi、jeecg-boot、芋道源码yudao等。它们普遍声称自带“完善的权限管理模块”但实际深度天差地别。前端权限仅控制了菜单显示并不等于后端真正限制了你访问这个接口。选型的时候一定要把平台的权限能力放在第一维度去评估。一个真正成熟的平台权限模块必须同时具备用户、角色、菜单、权限点管理数据权限部门/自定义数据范围操作日志与登录日志接口级别的安全校验而不只是前端路由拦截权限变更的实时生效支持多租户如果是SaaS类产品6.2 国产主流平台权限能力横向对比我可以聊几个比较有代表性的横向对比下各自定位**若依RuoYi**应该是国内使用率最高的快速开发平台之一。它的权限模型是非常标准的RBAC基于Spring Security实现支持按钮级权限。数据权限支持“全部/本部门/本部门及以下/仅本人/自定义”五种范围这在同类产品里是比较完善的。若依最大的优点是代码结构清晰、文档齐全适合二开。Jeecg-Boot的特点是“在线开发”更加重度低代码属性更强。权限模块同样支持按钮权限和数据权限前端基于Ant Design Vue交互体验比较现代。但从架构上看它比若依更庞大学习成本略高。**yudao芋道源码**是我个人比较欣赏的一个项目RESTful API设计规范、代码质量在线内置了RBAC体系、数据权限、SaaS多租户一套解决方案非常适合作为企业级中后台的脚手架。它的多租户数据隔离方案支持行级隔离和库级隔离两种级别这在快速开发平台里属于良心配置了。注意任何平台接进来都要先做一次权限模块的“体检”——用高权限账号建用户、建角色、配数据范围、验证接口越权防护。别只看后台界面做得好不好看直接拿接口文档和权限源码开刀。6.3 选型决策清单评审时逐条打钩选型会上对着这份清单打钩能大大降低后期翻车概率权限模型支持哪些维度用户/角色/权限/数据范围是否都有是否支持数据权限的“部门及以下”递归查询权限是后端校验还是纯前端控制必须是后端是否支持权限设置变更后即时生效比如通过Redis缓存刷新角色互斥/职责分离是否可配置是否提供完整的操作审计日志多租户场景是否支持独立的数据隔离社区活跃度如何、相关issue反馈速度二次开发难度如何核心权限代码耦合度是高是低是否内置了常用的RBAC管理页面用户管理、角色管理、菜单管理这十条里最要命的是第4条。很多平台的权限是写死在内存或者配置文件里的改权限必须重启服务这在生产环境里完全不可接受。6.4 低代码平台的权限黑匣子风险顺便提醒一句现在很多低代码平台声称“零代码配置权限”听起来很美。但你要警惕越是黑盒后面就越是枷锁。权限模型的复杂度会随着业务增长指数级上升低代码平台能做标准化场景但碰上“我们公司就是有这样的特批流程需要特殊处理”时低代码平台的扩展成本往往会让你怀疑人生。我的建议是低代码平台适合做原型和边缘系统核心业务系统的权限模型务必用可二次开发的代码级方案。7. 我在实际项目中的权限设计心得与体会写到这里分享几个我踩过的坑和慢慢沉淀下来的原则希望能帮你少走弯路。第一句话权限设计永远不要跳过数据范围这一步。很多项目一开始觉得“我们系统就几个角色不需要行级权限”结果业务跑起来后组织架构一调整就全线崩溃。行级权限不是大厂专属任何有多部门协作、多层级汇报关系的系统都需要。第二句话权限模块的代码越集中越好。不要把权限校验散落在业务Service层里这写一段那写一段。统一收敛到Spring Security的过滤器链/拦截器里配合注解驱动才能保证“一处配置、全局生效”。哪怕是临时特殊需求也优先通过新增权限点、新增数据范围策略来解决而不是堆if (user.isAdmin())。第三句话角色的命名和归类要有业务语义。我曾经见过一套角色表里混着“管理员”、“超级管理员”、“系统管理员”、“平台管理员”——四个角色权限还都不一样。这种僵尸角色多了以后没人敢动也没人说得清最终成了安全隐患。至少每个角色要能写清楚一句话的职责说明并且由“谁”在“什么流程”下才能分配。最后一句话也是我最近才深刻体会到的权限系统是“越早统一越省事”的典型代表。如果你正在启动一个新项目哪怕只是个小工具都建议把权限模型先按RBAC搭好。前期多付出的那点开发量相比后期改造的痛感简直不值一提。todo: 后续可以继续写一篇“权限模块性能优化百万用户下的缓存策略与热点Key治理”如果读者感兴趣评论区聊聊你们项目里的权限模型长什么样。 RBAC权限模型实战全解：从RABC0到数据权限与框架选型
1. 权限系统的本质你不是在写代码是在定规则做了这么多年Java后端我越来越觉得权限模型是绝大多数业务系统的“地基中的地基”。你可能有过这种经历项目快上线了产品突然说用户A能看到部门B的数据但用户C不行或者外部审计要求所有操作留痕你只能临时在Controller里塞一堆if判断。这些问题的根源往往不是代码写得差而是最开始就没把权限模型想清楚。权限系统到底解决什么问题用一句话概括它回答了“谁”能对“什么资源”做“什么操作”这个三元问题。RBACRole-Based Access Control基于角色的访问控制是目前最主流、也最适合绝大多数业务场景的答案。它的核心思想很朴素——把“权限”不直接绑在用户身上而是绑在“角色”上用户通过拥有角色来获得权限。为什么这个抽象如此重要因为现实世界中人和角色的关系是动态变化的。一个员工从销售岗调到市场岗如果权限直接绑在用户身上你就得一条条改这个用户的权限配置而有了角色这层“中间商”你只需要把他从“销售角色”挪到“市场角色”就行。这个“中间商”就是RBAC最大的价值——解耦。这篇文章不只是讲理论我会把RBAC从最基础的模型讲透再延伸到行级权限、数据范围这类实战中绕不开的难点最后结合我在多个项目中做权限模块的经验聊聊怎么评估一个快速开发平台的权限功能是否靠谱。面向的读者是Java后端开发、架构师以及正在选型快速开发平台的技术负责人。2. RBAC模型全拆解从只能应付demo到能上线生产2.1 基础RBACRBAC0到底包含哪些要素RBAC0是核心模型所有其他RBAC变体都是在这个骨架上长出来的。它定义了四类实体用户User、角色Role、权限Permission、会话Session。权限再细化一点可以拆成“操作”Operation和“资源”Resource两个维度。这个拆分非常重要很多初学者设计表结构时只建了一张“权限表”里面放个权限名称字符串结果后续根本没法做细粒度控制。我把权限拆成“操作资源”之后表结构通常是这样设计的用户表sys_user角色表sys_role用户角色关联表sys_user_role权限表sys_permission字段包括resource_type、resource_id、operation角色权限关联表sys_role_permission这套五张表的结构是RBAC0的经典落地方案。权限表里的operation我习惯用RESTful风格的动作来描述比如“查看用户列表”对应GET:/api/users而resource_id则指向具体的资源标识。这样设计的好处是以后想加细粒度限制不需要改表结构在既有框架上扩展就行。2.2 角色继承RBAC1和责任分离RBAC2复杂组织架构的救星现实中公司组织架构往往超过三层。集团有集团总裁分公司有分公司总经理部门有部门经理。如果每个层级都建一套独立的角色角色数量会爆炸而且职责边界会变得模糊。这时候就要用RBAC1的角色继承能力。角色继承在实现上我最推荐“树形结构”——子角色继承父角色的所有权限并在此之上增加自己的特有权限。举个例子“分公司总经理”继承“部门经理”的全部权限额外拥有跨部门审批的权限。在代码层面查询用户权限时要递归收集父角色的权限集合这里记得做去重和缓存不然沙雕递归性能会很难看。RBAC2则引入了约束概念包括互斥角色比如一个用户不能同时是“审批人”和“申请人”这在流程引擎场景巨常见和基数约束一个角色最多只能有XX个用户。我做过一个信贷审批系统就强制要求“初审员”和“终审员”不能是同一人这就是典型的静态职责分离。2.3 数据范围从功能权限到行级权限的天花板基础RBAC解决了“能不能访问这个菜单、能不能点这个按钮”的问题。但业务一旦跑起来你会发现真正的魔鬼藏在“能看到哪些数据”里。同样拥有“查看订单”权限的销售A和销售BA应该只能看到自己的订单B如果是个销售主管他应该能看到整个团队成员的订单。这就是行级权限Data Scope。业界最主流的方案是“部门数据范围”“用户数据范围”组合本人数据仅本人创建的数据本部门数据部门内所有成员的数据本部门及以下部门数据递归包含子部门全部数据不过滤常用于管理员角色的超级权限实现方案上我强烈建议在MyBatis层面做拦截器统一拼接数据权限SQL而不是在业务代码里手动加条件。手动加的问题是——你永远不知道哪个开发忘了加。我在项目里实现过基于注解DataScope的切面拦截在Mapper执行前动态注入SQL片段。核心思路是解析当前登录用户的数据范围类型然后生成对应的WHERE条件比如WHERE creator_id #{userId}或WHERE dept_id IN (...)。这个方案还有两个升级版玩法一是把数据范围本身也做成“角色权限的一部分”即角色表里加data_scope字段这样可以实现“同一个角色不同数据范围”的灵活配置二是结合机构树把部门表做成ancestors字段存储全路径这样查“本部门及以下部门”时就只需要一条LIKE查询性能远好于递归遍历。3. RBAC的常见变体与踩坑别一上来就搞最复杂的3.1 用户组User Group模型当角色数量失控时很多系统跑着跑着角色数量就失控了。一个电商后台运营一个角色、运营二组一个角色、数据专员一个角色、数据分析师一个角色……角色表越来越臃肿角色分配管理越来越痛苦。这时候引入用户组User Group是一个成熟的选择用户组本身就代表一批用户的集合你可以给组授权也可以给组里的某个用户额外授权。我见过不少优秀的开源项目比如若依框架就把用户组玩成了“岗位”的概念。用户组和角色的核心区别在于角色代表“权限集合”用户组代表“组织身份”。授权时两者可以同时生效取并集。这能极大降低权限配置的冗余度。3.2 ABAC什么时候值得上“属性权限控制”RBAC的局限在于权限模型的描述粒度是“角色”但真实世界有些规则无法简单用角色表达。比如“如果当前是工作日上午9点到12点允许提交加急订单”“只有当订单金额小于5000元时一线客服可以直接退款”——这种基于时间、金额、上下文等属性的动态决策RBAC表达起来很痛苦。这就是**ABACAttribute-Based Access Control基于属性的访问控制**的用武之地。ABAC的策略通常用规则引擎来管理Java生态里比较成熟的是Spring Security的注解式表达式配合PreAuthorize高度灵活但调试困难复杂规则容易变成“黑盒”。我的建议是90%的业务场景用RBAC就够了只有那些真正需要实时决策比如风控、审批流的子模块再引入ABAC并且把规则集中管理、加上完善的单元测试否则后期维护会非常酸爽。3.3 项目实战中的角色权限设计checklist跑过几个大型项目以后我总结了一份角色权限设计时需要自查的清单每次动权限模块都对着过一遍能省掉不少返工角色是否支持树形继承长期演进必备数据范围是否内置为权限维度这个是业务刚需不是可选项权限变更是否实时生效还是必须重新登录需求要提前定清楚是否存在互斥角色尤其涉及审批流、合规审计的场景是否预留了“特殊授权”通道比如临时给某个用户开某个接口的白名单这在运维场景很常见权限操作的日志是否完整谁在什么时候改了什么角色的权限——如果公司有审计要求这块是刚需4. Java权限框架的技术选型Spring Security和Shiro的取舍4.1 Spring Security体系庞大但值得长期投资Spring Security在Spring Boot项目中几乎是事实标准。它的核心链路是过滤器链Filter Chain——每个请求依次经过一系列过滤器实现认证、授权、会话管理等能力。这个模型在单体应用里很清晰在微服务架构下还能无缝集成OAuth2、JWT、OIDC。Spring Security的授权模型天然支持RBAC——GrantedAuthority就是角色/权限的抽象。你可以通过hasRole(ADMIN)、hasAuthority(user:list)等方式做细粒度控制。方法级别的安全还能用PreAuthorize做基于SpEL表达式的ABAC扩展。它的缺点也很明显学习曲线陡峭、配置繁琐。网上流传着“Spring Security是面试造火箭、工作拧螺丝”的说法有一定道理。但我的亲身感受是一旦项目上线、业务复杂起来Spring Security的扩展性优势就会迅速碾压Shiro。如果你做的是面向未来的中大型项目投资Spring Security是值得的。4.2 Apache Shiro轻量、易上手但边界明确Shiro最大的标签是“简单、直观”API设计非常友好。它的核心概念是Subject、SecurityManager、Realm。你只需要实现一个Realm告诉Shiro如何根据用户名查到用户和角色剩下的活儿它就自己干了。如果你的项目是中小型单体应用、权限模型就是“用户-角色-权限”三板斧Shiro完全够用。但Shiro有个硬伤它在Web安全防护比如CSRF、CORS、Session Fixation方面远没有Spring Security完善。而且随着Spring Security在Spring Boot里的开箱即用程度不断提升Shiro的“简单”优势也在缩小。选型建议表直接放这里维度Spring SecurityApache Shiro学习曲线陡峭平缓Spring Boot集成度原生级需额外适配Web安全防护完善较弱OAuth2/JWT支持原生支持需手写适合场景中大型、复杂授权、微服务中小型、简单RBAC社区活跃度极高一般4.3 轻量级权限框架到底怎么选一个自研小组件的思路很多团队最终发现无论是Spring Security还是Shiro在接入“行级权限”“按钮级权限”等业务需求时都需要大量自定义开发。既然如此我自己在项目中实践过一套轻量级权限组件思路值得分享认证直接基于JWT Token拦截器解析token、装载上下文授权基于注解拦截器实现RBAC校验支持类级别、方法级别的权限点配置数据权限在MyBatis层统一处理通过线程上下文获取当前用户的数据范围在SQL执行阶段动态改写这个轻量组件的核心价值不是“造轮子”而是让权限逻辑完全服务于业务模型而不是去迁就框架的限制。当然自研的前提是你对权限模型理解得足够深否则不如直接用Spring Security的扩展点改造。5. Spring Boot MyBatis下的RBAC落地实现手把手搭一套核心逻辑5.1 数据库建表与核心字段设计假设你的业务系统已经有用户表和部门表权限模型部分我建议直接建这五张表CREATE TABLE sys_role ( id BIGINT PRIMARY KEY, role_code VARCHAR(50) NOT NULL UNIQUE, role_name VARCHAR(100) NOT NULL, data_scope TINYINT NOT NULL DEFAULT 2 COMMENT 1全部 2本部门 3本部门及以下 4仅本人, status TINYINT DEFAULT 1, create_time DATETIME, update_time DATETIME ); CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY, perm_code VARCHAR(100) NOT NULL COMMENT 如 user:list, perm_name VARCHAR(100), resource_type VARCHAR(50) COMMENT menu/button/api, parent_id BIGINT DEFAULT 0 ); CREATE TABLE sys_role_permission ( role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, PRIMARY KEY (role_id, permission_id) ); CREATE TABLE sys_user_role ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id) );这里有个细节data_scope我放在角色表而不是用户表意味着“同一个用户如果拥有多个角色取数据范围最大的那个”。这是业务上最常见的规则但实现时一定要在代码里写清楚优先级否则后面排查数据可见性问题会想撞墙。5.2 核心鉴权拦截器逻辑简单细节魔鬼登录拦截器里做三件事解析Token、从缓存中加载用户权限、写入上下文ThreadLocal。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); Long userId JwtUtil.parseToken(token); // 从缓存取用户角色和权限集合避免每次请求都查库 SetString permissions permissionCache.get(userId); UserContext.set(userId, permissions); return true; } Override public void afterCompletion(...) { // 防内存泄漏一定要清理ThreadLocal UserContext.clear(); } }注意afterCompletion里的清理动作——我之前接过一个别人留下的项目ThreadLocal没清理Tomcat线程池复用后权限串号排查了一整天。这种问题不会立刻报错但会在流量上来后随缘出现属于最恶心的线上故障之一。5.3 数据权限动态SQL的实现思路行级权限的核心代码在MyBatis拦截器里。下面给出核心逻辑的伪代码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 { StatementHandler statementHandler (StatementHandler) invocation.getTarget(); // 获取原始SQL String originalSql statementHandler.getBoundSql().getSql(); // 根据当前用户的数据范围重写SQL String newSql rewriteSql(originalSql); // 通过反射修改boundSql.sql字段 Field field BoundSql.class.getDeclaredField(sql); field.setAccessible(true); field.set(statementHandler.getBoundSql(), newSql); return invocation.proceed(); } }这里忠告一句拦截器重写SQL是把双刃剑。它确实能帮你实现“无侵入”的数据过滤但SQL的规则复杂度一上来调试就是地狱。所以务必在开发环境打开MyBatis的SQL日志配合单元测试覆盖“不同数据范围下的SQL结果”。线上权限出错大概率就是这一步的问题提前把测试写稳比啥都强。6. 快速开发平台选型指南权限能力是第一硬指标6.1 为什么权限模型是选型的核心标准这些年我接触过很多快速开发平台包括若依RuoYi、jeecg-boot、芋道源码yudao等。它们普遍声称自带“完善的权限管理模块”但实际深度天差地别。前端权限仅控制了菜单显示并不等于后端真正限制了你访问这个接口。选型的时候一定要把平台的权限能力放在第一维度去评估。一个真正成熟的平台权限模块必须同时具备用户、角色、菜单、权限点管理数据权限部门/自定义数据范围操作日志与登录日志接口级别的安全校验而不只是前端路由拦截权限变更的实时生效支持多租户如果是SaaS类产品6.2 国产主流平台权限能力横向对比我可以聊几个比较有代表性的横向对比下各自定位**若依RuoYi**应该是国内使用率最高的快速开发平台之一。它的权限模型是非常标准的RBAC基于Spring Security实现支持按钮级权限。数据权限支持“全部/本部门/本部门及以下/仅本人/自定义”五种范围这在同类产品里是比较完善的。若依最大的优点是代码结构清晰、文档齐全适合二开。Jeecg-Boot的特点是“在线开发”更加重度低代码属性更强。权限模块同样支持按钮权限和数据权限前端基于Ant Design Vue交互体验比较现代。但从架构上看它比若依更庞大学习成本略高。**yudao芋道源码**是我个人比较欣赏的一个项目RESTful API设计规范、代码质量在线内置了RBAC体系、数据权限、SaaS多租户一套解决方案非常适合作为企业级中后台的脚手架。它的多租户数据隔离方案支持行级隔离和库级隔离两种级别这在快速开发平台里属于良心配置了。注意任何平台接进来都要先做一次权限模块的“体检”——用高权限账号建用户、建角色、配数据范围、验证接口越权防护。别只看后台界面做得好不好看直接拿接口文档和权限源码开刀。6.3 选型决策清单评审时逐条打钩选型会上对着这份清单打钩能大大降低后期翻车概率权限模型支持哪些维度用户/角色/权限/数据范围是否都有是否支持数据权限的“部门及以下”递归查询权限是后端校验还是纯前端控制必须是后端是否支持权限设置变更后即时生效比如通过Redis缓存刷新角色互斥/职责分离是否可配置是否提供完整的操作审计日志多租户场景是否支持独立的数据隔离社区活跃度如何、相关issue反馈速度二次开发难度如何核心权限代码耦合度是高是低是否内置了常用的RBAC管理页面用户管理、角色管理、菜单管理这十条里最要命的是第4条。很多平台的权限是写死在内存或者配置文件里的改权限必须重启服务这在生产环境里完全不可接受。6.4 低代码平台的权限黑匣子风险顺便提醒一句现在很多低代码平台声称“零代码配置权限”听起来很美。但你要警惕越是黑盒后面就越是枷锁。权限模型的复杂度会随着业务增长指数级上升低代码平台能做标准化场景但碰上“我们公司就是有这样的特批流程需要特殊处理”时低代码平台的扩展成本往往会让你怀疑人生。我的建议是低代码平台适合做原型和边缘系统核心业务系统的权限模型务必用可二次开发的代码级方案。7. 我在实际项目中的权限设计心得与体会写到这里分享几个我踩过的坑和慢慢沉淀下来的原则希望能帮你少走弯路。第一句话权限设计永远不要跳过数据范围这一步。很多项目一开始觉得“我们系统就几个角色不需要行级权限”结果业务跑起来后组织架构一调整就全线崩溃。行级权限不是大厂专属任何有多部门协作、多层级汇报关系的系统都需要。第二句话权限模块的代码越集中越好。不要把权限校验散落在业务Service层里这写一段那写一段。统一收敛到Spring Security的过滤器链/拦截器里配合注解驱动才能保证“一处配置、全局生效”。哪怕是临时特殊需求也优先通过新增权限点、新增数据范围策略来解决而不是堆if (user.isAdmin())。第三句话角色的命名和归类要有业务语义。我曾经见过一套角色表里混着“管理员”、“超级管理员”、“系统管理员”、“平台管理员”——四个角色权限还都不一样。这种僵尸角色多了以后没人敢动也没人说得清最终成了安全隐患。至少每个角色要能写清楚一句话的职责说明并且由“谁”在“什么流程”下才能分配。最后一句话也是我最近才深刻体会到的权限系统是“越早统一越省事”的典型代表。如果你正在启动一个新项目哪怕只是个小工具都建议把权限模型先按RBAC搭好。前期多付出的那点开发量相比后期改造的痛感简直不值一提。todo: 后续可以继续写一篇“权限模块性能优化百万用户下的缓存策略与热点Key治理”如果读者感兴趣评论区聊聊你们项目里的权限模型长什么样。