1. RBAC权限模型到底解决了什么问题1.1 从一个常见的权限场景说开去我做后端开发这些年接手过不少带权限需求的系统最典型的一个场景是这样的企业内部有个后台管理系统里面有不同的业务角色比如运营人员能看订单数据和用户反馈财务人员只能看结算和账目而部门主管除了能看还能审批。早期项目怎么做权限直接在代码里写死比如在Controller方法里搞一个判断如果当前登录用户的用户类型等于管理员就放行。这种方案在角色只有三五个、接口几十个的时候还算能跑但一旦角色膨胀到十几个接口上百个代码就完全失控了。后来我意识到权限管理的本质其实不是“这个用户能不能访问这个接口”而是“这个人属于什么角色这个角色被授予了哪些权限”。这就是RBACRole-Based Access Control基于角色的访问控制模型的核心思想。Spring Security 做集成的意义也在于此它不是一个独立的权限系统而是一个安全框架的骨架RBAC 是我们在骨架上填进去的业务逻辑。两者结合才能既拿到 Spring Security 的过滤器链、会话管理和密码加密能力又保留下权限模型按角色、按资源灵活配置的空间。Spring Security 集成 RBAC解决的核心问题有三个第一把用户、角色、权限之间的关系从代码中抽离出来变成数据层面的配置第二让权限变更不需要重新发版运营或者管理员在后台改一下角色权限就能生效第三统一认证和授权入口不要再散落在各自业务代码里做 if-else。1.2 RBAC的结构拆解用户、角色、权限的三层关系RBAC 从数据模型上拆开就三层用户User、角色Role、权限Permission。用户通过角色间接获得权限而不是用户直接跟权限挂钩。为什么一定要中间隔一层角色我举个生活中的例子一家公司里张三今天入职做后端开发他需要 git 仓库权限、服务器部署权限、文档平台权限。如果这些权限直接绑在张三这个人身上那明天如果张三转岗做产品经理你就得把他身上十几个权限一个个解绑再重新绑累不累但如果在角色层有一个“后端开发”的角色你只需要把张三从后端的角色里挪出去加进产品经理的角色组权限就自动切换了。所以 RBAC 的核心价值不是技术上的而是管理上的。它让权限的分配和维护变成“给人分配角色”这么简单的一件事。实际项目中我们通常还会演化出用户-角色多对多、角色-权限多对多这两组关系。用户和角色多对多意味着一个人可以同时拥有“运营”和“班组长”两个角色角色和权限多对多意味着一个权限点可以被多个角色共同拥有。1.3 把权限点落在“资源操作”上在 RBAC 落地时最容易被忽视的是权限怎么去定义。很多团队把权限设计成“查看订单”“删除用户”这样一段文字描述然后存到数据库里代码里判断的时候拿字符串去比较。这个做法不是不行但它很难长期维护原因很简单字符串判断容易在代码里散落而且权限点和实际接口之间没有建立明确关联。我习惯把权限点定义为“资源 操作”的组合比如订单列表这个接口对应资源是 order操作是 list订单删除接口对应 order:delete。这样在 Spring Security 里就很好映射了一个权限点本质上就是一个可以校验的字符串标识。这个思路在后面动态权限过滤时特别重要因为 Spring Security 的授权判断最终都要落到一个权限标识的匹配上。2. 数据库表设计与权限模型落地2.1 五张标准表从用户到权限的链路RBAC 在关系型数据库里的落地我基本固定使用五张表这个结构在绝大多数项目中都能直接套用用户表sys_user存账号和加密后的密码字段最少要有 id、username、password、status、create_time。其中 status 是常用的软禁用标记被禁用的用户在登录时直接被拦截掉而不是把账号删掉这个在后续遇到离职员工或异常账号处理时很管用。角色表sys_role存角色标识和描述典型字段包括 id、role_code、role_name。role_code 才是代码里真正去匹配用的值比如 ADMIN、OPERATOR、FINANCErole_name 只是给人看的。很多人喜欢拿中文名做匹配我不建议中文带个空格或者别名一变你就得改代码。权限表sys_permission就是前面说的权限点字段包括 id、perm_code、perm_name、resource_type。resource_type 你可以先简单理解成菜单、按钮、接口这种分类实际用的时候我一般把 perm_code 设计成类似 order:list、order:delete 这种格式。中间两张关联表sys_user_role存用户和角色的关系sys_role_permission存角色和权限的关系。有了这两张关联表整个链路就通了通过 userId 查出角色再通过角色集合查出权限码集合。2.2 建表 SQL 与初始化数据的注意事项建表 SQL 我就不完整贴了说几个关键点。第一所有关联表的主键直接用自增 id 就行别去搞复合主键后续做权限批量删除和重新分配的时候方便得多。第二用户表密码字段长度最少设 60因为 BCrypt 加密后的字符串长度就是 60我之前见过有人设成 varchar(20)结果项目一启动注册接口直接报数据超长。第三角色表加一个唯一索引在 role_code 上防止同名的角色被重复插入。初始化数据也有讲究。系统启动阶段至少要把三样基础数据准备出来一个内置管理员账号、一个超级管理员角色、以及超级管理员角色的所有权限。注意超级管理员角色的权限在项目初始化时是不能空的否则你在开发阶段登录进去发现什么接口都访问不了排查半天发现自己把自己锁在外面了。这种事情我踩过当时新同事在测试环境初始化了权限表但漏掉了管理员角色的权限关联结果登录进去接口全是 403大家都以为是 Spring Security 配置出了问题。2.3 为什么说“接口即权限点”在 RBAC 落地到 Spring Security 的过程中最重要的映射关系就是“接口地址 HTTP 方法”对应一个权限点。比如GET /api/order/list对应 order:listDELETE /api/order/{id}对应 order:delete。这么设计的好处是你可以做一个权限点管理页面把系统的接口清单自动扫描出来然后让管理员在后台配置哪些角色可以访问哪些接口。权限点与接口一一对应之后动态权限控制的实现就变得统一了。Spring Security 里的过滤器只需要做一件事拿到当前请求的 URL 和 HTTP 方法从自己的权限表里去匹配应该需要哪些权限码然后查看当前登录用户拥有的权限码集合里是否包含匹配项。整个过程不涉及任何业务代码。这套思路是我在实际项目里反复验证过的比在 Controller 里写死注解要灵活得多后面我会详细讲代码实现。3. Spring Security 整合代码一步步来3.1 依赖引入与版本选择的经验Spring Boot 项目集成 Spring Security 很简单引入一个起步依赖就行。但版本选择上我多说一句如果你用的是 Spring Boot 2.x那 spring-boot-starter-security 会自动拉到 5.x 的 Spring Security如果是 Spring Boot 3.x对应的就是 Spring Security 6.x。这两个大版本在配置方式上有不少差异特别是WebSecurityConfigurerAdapter已经被废弃了现在推荐直接注册SecurityFilterChain的 Bean。我第一次从 5 升级到 6 的时候因为还在用旧的写法项目直接启动失败报错提示明确说这个类已经移除。所以如果你是新项目或者正在升级直接按 Spring Security 6 的新写法来不要去翻老教程。除了安全框架本身还需要数据库访问组件。我用的是 MyBatis-Plus在 RBAC 这三层模型里它的作用主要是简化单表 CRUD。当然你用 MyBatis、JPA 还是更底层的 JDBC 都没有关系安全框架本身跟 ORM 没有强绑定只要能查出用户信息、角色列表和权限码集合就可以。我个人偏好 MyBatis-Plus 是因为它支持自定义 SQL 和 LambdaQueryWrapper写关联查询和批量条件查询都比较顺手。3.2 打通用户表到登录态的认证链路Spring Security 集成 RBAC第一步是让 Security 认识我们的用户。Security 内部通过UserDetailsService这个接口来加载用户信息默认实现是从内存里查用户我们要做的就是把默认实现替换成从数据库查询。具体做法是实现UserDetailsService接口的loadUserByUsername方法在里面做三件事根据用户名查出用户记录查出这个用户拥有的角色集合查出这些角色对应用户拥有的权限码集合。然后把它们组装进 Spring Security 的UserDetails对象。这里有个容易踩坑的地方UserDetails接口里的getAuthorities()返回的是权限集合它的泛型是GrantedAuthority。很多人一开始只把角色塞进去比如返回ROLE_ADMIN然后后面做权限判断时发现自定义的权限码根本匹配不上。我的做法是把角色和权限码都放进authorities里角色用ROLE_前缀权限码保持原样。这样在后续配置里既可以用hasRole()判断角色也可以用hasAuthority()判断权限两边都不耽误。组装好UserDetails后登录流程就交给 Spring Security 自己管理了。默认情况下它会走表单登录我们项目里做的是前后端分离所以改成 RESTful 的 JSON 登录方式即自定义一个登录接口通过AuthenticationManager的authenticate()方法手动触发认证。认证成功后把用户信息和权限码存进 SecurityContext后续请求就能从 SecurityContext 里拿到完整的权限数据。3.3 SecurityConfig 配置类的完整形态Spring Security 6 的核心配置类是注册一个SecurityFilterChainBean。我整理一份常用的配置骨架这个骨架在多个项目里复用过了基本可以直接抄Configuration EnableWebSecurity EnableGlobalMethodSecurity(prePostEnabled true) public class SecurityConfig { Resource private UserDetailsService userDetailsService; Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } Bean public AuthenticationManager authenticationManager(AuthenticationConfiguration config) throws Exception { return config.getAuthenticationManager(); } Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf(csrf - csrf.disable()) .sessionManagement(session - session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth - auth .requestMatchers(/api/auth/login, /api/auth/captcha).permitAll() .anyRequest().authenticated() ) .exceptionHandling(ex - ex .authenticationEntryPoint(unauthorizedHandler) .accessDeniedHandler(accessDeniedHandler) ); return http.build(); } }这段配置里要特别注意的是EnableGlobalMethodSecurity注解在 Spring Security 6 里它被标记为过时推荐换成EnableMethodSecurity。如果你的项目用的还是旧写法启动时会看到 deprecated 警告不影响运行但建议尽早改。prePostEnabled true的意义是启用PreAuthorize这类方法级注解后面在 Controller 或者 Service 方法上可以直接用注解做细粒度校验。另外记得把UserDetailsService注入容器。Spring Security 会自动检测到它并使用不然默认会去内存中查找用户导致你数据库里的账号永远登录不上。3.4 静态权限与动态权限两种路线的取舍Spring Security 授权判断有两种常见的落地路线我把它称为静态权限和动态权限。静态权限就是在方法上或者配置里写死权限码比如在 Controller 方法上标注PreAuthorize(hasAuthority(order:delete))。这种方式直观、代码可读性好适合权限点相对固定、角色数量少的项目。缺点是权限一变就要改代码发版运维成本明显偏高。另外如果项目里接口量很大每个方法上都挂注解代码会显得很臃肿。动态权限则是让安全框架在请求到达时根据请求的 URL 去数据库查询对应的权限码再与当前用户拥有的权限做比对。这种方式把权限配置彻底迁移到了后台权限变更无需改代码是 RBAC 真正价值最大化的方案。代价是需要实现 Spring Security 里的FilterInvocationSecurityMetadataSource和AccessDecisionManager两个核心接口代码复杂度明显提升。我自己的习惯是小项目或者企业内部低并发系统静态权限就够了够清晰、够直白。一旦权限点超过两三百个或者有多个角色且权限经常调整我毫不犹豫选择动态权限。后面一节我会完整讲动态权限的实现细节因为这是 Spring Security 集成 RBAC 最有含金量的一段。4. 动态权限过滤器的实现细节4.1 核心类一FilterInvocationSecurityMetadataSourceFilterInvocationSecurityMetadataSource的作用是决定“当前请求需要哪些权限”。实现它的getAttributes()方法入参是当前请求的封装对象返回值是一个ConfigAttribute集合也就是访问这个请求所必须具备的权限条件。我的实现思路是这样的先从请求里取出 method 和 URI然后去缓存中查询一份“权限-URL 映射表”匹配对应的权限码。这个映射表在系统启动时从数据库加载结构大概是GET /api/order/list - order:list。如果匹配不到任何权限记录说明这个接口没有配置权限限制直接返回 null走到下一步的匿名访问或认证访问。这里有个细节容易出错请求 URI 经常带路径参数比如/api/order/detail/123而数据库中配置的权限对应的是匹配/api/order/detail/*这样的模式。如果直接拿完整 URI 去做精确匹配肯定匹配不上。所以我在实现时是用AntPathRequestMatcher来做路径匹配把 URI 按规则去和权限表中的 URL 模式做匹配而不是字符串相等。这一步解决了 90% 的动态权限配置位置不对的问题。4.2 核心类二自定义 AccessDecisionManager有了“当前请求需要哪些权限”接下来就轮到AccessDecisionManager决定“当前用户是否满足这些权限要求”。这个接口的decide()方法会拿到三个关键参数当前认证信息、请求对象以及上一节返回的ConfigAttribute集合。我实现的decide()逻辑分三步第一步如果ConfigAttribute集合为空说明这个接口不需要特定权限直接放行。第二步遍历ConfigAttribute提取出权限码。第三步从当前认证信息中拿到用户拥有的权限集也就是UserDetails中的 authorities判断是否包含任意一个需要的权限码。如果我实现了“多角色满足其一即可访问”的需求这里用交集不为空来判断如果某些接口要求必须同时具备多个权限那就改成包含关系判断。一个需要注意的点是这个管理器必须显式配置到HttpSecurity上面不配置的话 Spring Security 默认走它自己内置的投票器逻辑不会调用我们的实现。我第一次做的时候就漏配了这个结果自定义管理器一点反应都没有排查了很久。配置方式很简单在filterChain里加上这样一段http.authorizeHttpRequests(auth - auth .anyRequest().authenticated() .withObjectPostProcessor(new ObjectPostProcessorFilterSecurityInterceptor() { public O extends FilterSecurityInterceptor O postProcess(O object) { object.setAccessDecisionManager(customAccessDecisionManager()); object.setSecurityMetadataSource(customSecurityMetadataSource()); return object; } }) );这里的withObjectPostProcessor是给过滤器拦截器注入自定义组件的关键入口官方推荐的写法在 Spring Security 6 里就是通过它来替换默认实现。贴代码时我发现这个写法有版本兼容性差异在 6.1 以后部分接口签名有调整如果你在编译期报错优先检查依赖版本和官方文档。4.3 用户角色与权限的缓存策略动态权限方案在开发环境一切正常一上生产就面临一个现实问题每个请求都去数据库查权限表接口响应变慢。特别是一个系统里用户量大、接口多、权限配置复杂的时候这种全量查询的代价会源源不断地体现出来。我的做法是按两个维度做缓存。第一维度是“URL 到权限码”的映射这个全局只有一份适合用本地缓存容器或 Redis 存放启动时加载权限改动时刷新。第二维度是“用户到权限码集合”这个按用户维度缓存通常在登录或者首次访问时加载有效期设置为 30 分钟。用户被调整角色之后最多等缓存过期就能生效如果要求实时生效可以在后台调配角色时主动删除该用户的缓存键下一次请求就重新从数据库拉取。这里要特别提醒缓存用户权限时不要只缓存角色标识。因为最终判断权限用的是权限码集合如果只存角色后面权限码一变你都无从判断。同时权限变更时缓存刷新要设计成全局性的不然会出现用户明明被加了权限但访问还是 403 的诡异现象。5. 线上排障与性能踩坑记录5.1 401 和 403 分不清请求进不到业务层这是我被问得最多的一类问题。现象是前端调用接口返回 401 或者 403前端一脸懵后端也觉得配置没问题。其实这两个状态码在 Spring Security 里有明确分工401 表示未认证即请求里没有携带有效的 token 或者会话已经过期403 表示已认证但权限不足即你有身份但你无权访问这个接口。排查的时候第一步就是分清你现在是没登录还是没权限。最简单的办法是看后端日志里打印的认证信息如果Authentication是匿名对象AnonymousAuthenticationToken那说明请求根本没有携带有效的认证凭证如果用户名都打出来了还是 403那问题几乎可以断定在授权链路。授权链路常见的问题就两类一类是自定义AccessDecisionManager没有被加载Spring Security 还在用默认的投票器另一类是权限码匹配不上比如数据库存的是order:list你代码里判断的却是order:list!这种带了特殊字符或者前后空格的值。我见过太多因为权限码两边不一致导致的排障噩梦最有效的预防手段是在系统启动时做一次权限码合法性校验扫描所有代码里用到的权限和数据库里的权限配置做差集比对把不一致的直接打印出来。5.2 密码加密引发的登录失败问题项目切换成 Spring Security 之后账号密码校验走的是框架内置的PasswordEncoder。很多人第一次集成时直接把PasswordEncoder设成NoOpPasswordEncoder也就是明文不加密图省事。短期内本地开发没问题一旦部署到测试环境或者生产之前要接入真实密码数据就麻烦了。已经入库的密码是明文而生产环境你不可能允许把密码明文存着。我的建议是从一开始就使用BCryptPasswordEncoder即使是在开发阶段。BCrypt 的好处在于同一密码每次加密的结果都不同因为带随机盐这保证了你无法通过比较密文来反推明文安全性比 MD5 加盐高得多。而且对于已经存了 MD5 密码的老系统你可以在校验逻辑里做一个兼容先按 BCrypt 校验失败再按 MD5 校验校验成功就把密码升级成 BCrypt 存储。这一步看起来很不起眼但真的能省掉系统切换时的数据迁移大工程。5.3 权限缓存命中率低数据库压力大动态权限方案上线后权限接口每次请求都会频繁访问缓存。如果权限缓存设计不当比如把每个用户的权限码单独存一个 key用户量又大缓存命中率会很低数据库压力反而比不加缓存时更大。我后来调整的策略是权限点配置信息不按用户维度缓存而是全局一份存放到本地内存或者 Redis 的固定 key 下。这样不管哪个用户来访问同一个 URL命中的都是同一条缓存记录命中率接近 100%。而用户维度的缓存只存用户权限码集合并且让这个集合在登录认证期间完成加载后续请求全部走内存读取。权限变更不太频繁的系统这种方案完全够用。如果权限变更非常频繁比如每隔几分钟就有人调整角色权限那可以考虑给权限配置加上一个版本号每次修改就递增版本号客户端每次检查版本号不一致就重新拉取。这种方法稍微复杂一点但对于中大型系统来说是值得的。5.4 接口路径匹配的经典坑Ant 模式的边界问题动态权限中 URL 与权限点匹配核心是 Ant 路径表达式。这里有个经典陷阱/api/order/**匹配/api/order/list但它也匹配/api/order/delete/123。如果你的权限点是/api/order/list精确匹配而另一个接口是/api/order/delete/**对应另一个权限点那么请求/api/order/delete/123时可能会被/api/order/**这条规则先匹配上导致落入错误的权限判断。我的解决方式是给权限表增加一个字段叫match_type及时指定精确匹配还是通配匹配在匹配时优先精确匹配如果找不到再走通配匹配。这样的顺序能保证不会出现权限范围放大或者缩小的问题。另外接口路径匹配一定要严格区分 HTTP 方法GET /api/order和POST /api/order在语义上完全不同匹配规则里必须把 method 一起参与判断。6. 过程中的工具与调试技巧6.1 借助 Spring Security 的过滤器链定位问题Spring Security 的机制是基于过滤器链的从请求进入容器到到达 Controller中间经过了几十个过滤器。一旦遇到莫名其妙的 401 或者请求被重定向直接 debug 进栈看过滤器顺序是最高效的方式。Spring Boot 启动时只要把日志级别调到 DEBUG控制台会打印完整的过滤器链顺序。看到类似FilterChainProxy[TokenFilter, BasicAuthenticationFilter, AuthorizationFilter]这样的输出你就能判断当前启用的过滤器有哪些、顺序如何。大多数权限判断出问题都是过滤器执行顺序与预期不一致导致的。比如自己写的 token 校验过滤器没有排在认证过滤器之前token 都还没被解析框架就已经认为你是匿名的了。6.2 权限调试的快速验证接口集我在实际开发中会维护一套本地调试用的接口集合覆盖典型的权限场景一个放行接口、一个需要认证的接口、一个需要特定权限的接口、一个管理员权限接口。每次改完权限配置我只要依次请求这四个接口就能快速判断权限链路是否正常。放行接口返回 200说明放开配置生效了。需要认证的接口不带 token 时返回 401带普通用户 token 时返回 200说明认证链路通畅。需要特定权限的接口带没有权限的用户 token 返回 403带拥有权限的用户 token 返回 200说明授权判断正常。这四组测试跑完整个权限链路基本没有大问题了。这套方法比单纯用单元测试更贴近真实环境我每次重构权限模块都会先跑一遍。6.3 单元测试里注意 SecurityContext 的清场写完权限逻辑顺手会补几个单元测试。用 MockMvc 测试带认证的接口时我踩过一个大坑测试方法之间共享了 SecurityContext第一个用例设置了用户 A 的上下文第二个用例没设置新的上下文直接沿用上一个用户跑了结果权限判断完全不是你预期的。原因在于 MockMvc 的上下文是线程绑定的测试方法在同一个线程里执行时如果不清理就会串。解决办法是在每个测试方法结束或者开始前主动清一下SecurityContextHolder.clearContext()或者用一个AfterEach注解把清理逻辑统一挂上。这个小问题排查起来很费时间知道之后两分钟就能避免。7. RBAC 之外我们还要补什么7.1 数据权限和字段权限是另一层问题RBAC 解决了功能权限即什么角色能访问什么接口。但它不解决数据权限也就是同一接口下不同角色能看的数据范围不同。比如运营能看到全部订单但普通销售只能看自己名下的订单。这类需求需要在业务层通过数据权限规则来实现比如在查询语句中拼接所属部门的过滤条件。我在项目里是这样处理的将功能权限交给 Spring Security 统一处理数据权限留给业务层通过自定义注解加 AOP 来拦截。具体做法是定义一个DataScope注解标注在 Service 方法上里面写上需要隔离的部门字段名AOP 拦截后在查询前自动拼接数据范围条件。这样可以避免在每个方法体里手写判断又能保持灵活性。Spring Security 本身对数据权限并没有原生支持所以做系统设计时不要指望一个安全框架能解决所有权限问题。把功能权限和数据权限的边界划分清楚整个系统的权限体系才能撑得住复杂业务。7.2 操作审计是权限系统的另一半权限系统上线后还有一个很容易被忽略的部分操作审计。我见过很多团队权限做得很好但出了数据问题之后查不到是谁干的。权限控制只是事前的拦截事后的追溯同样重要。我一般会用一个 AOP 切面拦截所有 Controller 方法记录操作人、操作时间、请求路径、参数和返回结果。这里有个重点一定不要只记录成功请求失败的请求和权限拦截的请求也需要记录因为往往异常操作就是通过这些日志暴露出来的。Spring Security 的Authentication对象里保存了当前登录用户的信息可以直接在 AOP 切面中获取。切面执行顺序上要注意权限校验的过滤器先于 AOP 执行所以记录日志的时候拿到的一定是已经通过认证的用户身份不会出现匿名用户的情况。如果配合上用户登录日志基本就能复原任一操作的时间线和操作链。权限系统加上审计日志这个闭环才算完整。8. 从实际经验里总结的几点体会8.1 权限系统要早设计不要等到接口多了再补权限如果等项目快做完了再回头集成成本是最高的。原因很简单前期所有接口都没有权限意识代码里到处是裸奔的接口到时候你要做的是给几百个接口逐个配置权限点还要确保没有漏掉任何一个暴露在外的敏感接口。这个工作量比从零开始规划大得多。我自己经历过一个走查漏配的项目当时测试拿一个普通用户 token 把 GET 请求接口遍历了一遍发现好几个内部管理接口可以直接访问仅凭用户名登录就能拉取所有用户的数据。事后排查结论是这些接口在权限表里压根没有配置对应的权限点被自定义的 metadata source 判定为“无需权限”放行了。这种风险一旦漏掉一个就是数据事故级别。我的建议是权限点配置要跟着接口开发同步走接口联调完权限配置就到位而不是集中到最后一起补。8.2 Spring Security 和 RBAC 的关系要拎清楚很多刚接触这两样东西的开发者会误以为 Spring Security 就是个 RBAC 框架其实它不是。Spring Security 是一个安全框架认证、会话、CSRF、过滤器链这些是它真正擅长的领域而 RBAC 是一套权限模型描述的是数据关系和管理规则。用 Spring Security 实现 RBAC本质上是在这套安全的框架里把我们自定义的用户、角色、权限数据模型嵌入到它的认证与授权流程中。理解这一点你在看官方文档时就不会老觉得各处对不上因为框架本身没有提供现成的五张表和角色管理接口这些全部由我们自己去构建。8.3 权限配置后台一定要有权限自管理最后提一个容易被忽略但非常实用的功能权限后台要能自己管理自己。也就是说管理员登录系统后不但在后台配置其他用户的角色权限还要能修改当前用户所属角色的权限。这样权限模块本身就是一个完整的管理功能而不只是开发期的技术支撑。这个功能做完业务团队也能自行调整角色权限逻辑不需要每次都找开发改数据表或重启服务。配合上本文前面提到的权限缓存刷新机制整个 RBAC 权限系统就能形成一个可以自洽循环的完整闭环。
