RBAC推荐入门到精通，这份后端学习路线请收好

RBAC 从入门到精通：后端权限学习路线

RBAC 的核心不是“多写几张表”，而是把用户、角色、权限解耦：用户不直接绑定权限，而是通过角色获得权限。这样在人员变动、岗位调整、权限回收时，系统不会迅速失控。

1. 先搞懂 RBAC 在解决什么问题

没有 RBAC 时，用户和权限是网状绑定：一个用户可能有几十个权限，一个权限也可能分给很多人。人越多，越难维护，离职、转岗、临时授权都容易漏。

RBAC 把它变成：

用户 → 角色 → 权限

比如客服角色拥有“查看用户、查看订单、处理工单”，所有客服只要绑定这个角色即可。权限变更时，只需要改角色，不需要逐人修改。

2. 掌握 RBAC 四个层级

RBAC0 基础模型：用户、角色、权限三层关系，适合大多数后台系统。

RBAC1 角色继承：上级角色自动继承下级角色权限，适合有明确职级体系的团队。

RBAC2 角色约束：加入互斥角色、职责分离，比如会计和出纳不能由同一人担任。

RBAC3 综合模型：继承 + 约束 + 审计，适合金融、政务、医疗等高合规场景。

实战建议：90% 的企业后台，RBAC0 + 数据权限已经足够。

3. 数据库设计：至少五张表

典型结构是：

sys_user：用户表

sys_role：角色表

sys_permission / sys_menu：权限或菜单表

sys_user_role：用户与角色的多对多关系

sys_role_permission：角色与权限的多对多关系

权限标识建议统一命名，例如：

system:user:list

system:user:create

order:refund

finance:invoice:export

菜单、按钮、接口可以统一用一张权限表管理，通过类型区分：目录、菜单、按钮、API。

4. 后端落地：从拦截到缓存

后端权限校验通常走这几步：

用户登录，生成 Token 或 Session。

根据用户查询角色，再查询角色下的权限集合。

将权限集合缓存到 Redis，避免每次请求都查库。

接口层通过注解、中间件或 AOP 拦截请求。

比对当前接口需要的权限标识，例如 order:delete。

无权限则返回 403，有权限则继续执行业务逻辑。

Java 体系可以用 Spring Security、Shiro;Go 可以用中间件 + Casbin;PHP 也可以用 Casbin 做策略引擎。

5. 必须补上“数据权限”

RBAC 解决的是“能不能做”，数据权限解决的是“能看到哪些数据”。

常见数据范围：

仅本人数据

本部门数据

本部门及下级部门

指定部门

全部数据

实现方式通常是在查询 SQL 中动态拼接条件，例如自动加上 department_id = ? 或 creator_id = ?。注意这里要做 SQL 注入防护和字段白名单校验。

6. 进阶路线：从可用到可靠

权限缓存：用户权限放入 Redis，权限变更时主动失效。

最小权限原则：不要默认给管理员，按需分配。

角色不要过深：继承层级控制在 2-3 层，避免排查困难。

职责分离：敏感岗位设置互斥角色。

审计日志：记录权限变更、角色分配、越权访问。

灰度与审批：敏感权限变更走审批流，避免误操作。

7. 推荐学习顺序

先看 RBAC0 概念和五张表设计。

手写一个最简单的“用户-角色-权限”查询。

加上接口权限拦截。

加上菜单权限和按钮权限。

加上 Redis 权限缓存。

补上数据权限。

再考虑角色继承、互斥角色、审计日志。

最后了解 RBAC + ABAC 混合模型，比如用 OPA/Casbin 做动态策略。