根因业务系统OA、后台管理、ERP、企业数字化平台必然存在权限控制需求。最简单的权限写法直接给用户写死判断if($user_id 1) {允许操作}。这种硬编码方式用户一多、岗位变动代码改不停完全无法维护。RBACRole-Based Access Control基于角色的访问控制核心思想不给用户直接绑定权限中间增加一层「角色」做隔离。用户绑定角色角色绑定权限。当岗位变动只需要更换用户的角色不用修改权限本身也不用改代码。它是企业后台系统最通用的权限模型PHP开发管理后台几乎必用也是十五五数字化平台标准组件。核心一句话用户 ← 角色 → 权限角色作为中间桥梁解耦用户和权限。一、核心基础术语用户 User使用系统的人。账号主体比如管理员、财务、运营。一个用户可以分配多个角色。角色 Role岗位/身份的抽象例如超级管理员、财务、运营、普通查看员。角色是权限的集合载体。权限 Permission最小粒度的可操作点。分为两种功能权限、数据权限。功能权限按钮、接口、菜单例如新增订单、删除用户、查看菜单。数据权限能看到哪些业务数据例如只能看自己部门订单还是全公司订单。用户-角色关联 User-Role多对多关系。一个用户可以拥有多个角色同一个角色可以分配给多个用户。数据库一般单独一张中间表user_role存储。角色-权限关联 Role-Permission多对多关系。一个角色包含多条权限同一个权限可以归属多个角色。数据库中间表role_permission。二、RBAC的4个经典版本RBAC0 ~ RBAC3RBAC0基础版绝大多数后台用这个最基础模型用户、角色、权限两张多对多关联表。支持用户多角色角色多权限。日常PHP开发的后台权限基本都是RBAC0。没有角色继承、没有约束。RBAC1带角色继承在RBAC0基础上增加角色层级继承。例子总监角色自动继承下属主管角色全部权限。角色可以单向继承子角色拥有父角色权限。优点减少权限重复配置缺点层级复杂后权限不好排查。RBAC2带约束在RBAC0基础上增加业务约束规则互斥角色同一个用户不能同时拥有两个互斥角色。比如不能同时是“申请人”和“审批人”。基数约束某个角色最多只能分配给N个人。例如超级管理员最多2人。先决条件角色想要分配角色A必须先拥有角色B。RBAC3RBAC1RBAC2合并继承 约束是完整标准RBAC模型大型复杂企业系统才会使用中小型后台很少落地。三、扩展高频术语实际开发必遇到菜单权限权限的一种表现形式。控制左侧菜单是否展示。本质是权限前端根据后端返回的权限列表渲染菜单。误区菜单隐藏不等于接口安全。前端隐藏菜单直接调用接口依然能访问权限校验必须放在后端。按钮权限同一个页面不同角色看到不同按钮。例如普通员工只能查看管理员才有删除按钮。同样前端只是控制按钮显示后端接口必须二次校验。数据权限行级权限RBAC原生标准只定义功能权限。数据权限属于RBAC的扩展不属于标准RBAC。功能权限控制“能不能做这个操作”数据权限控制“能操作哪几条数据”。例子销售A只能看自己创建的客户销售经理可以看本部门全部客户。实现方案在SQL中自动追加数据范围条件。资源 Resource权限保护的目标对象。接口、页面、文件、数据表都叫资源。操作 Operation对资源的动作查看、新增、修改、删除。权限经常设计为「资源:操作」格式例如order:create、user:delete。这种字符串标识就是权限标识符PHP项目里非常常用。权限白名单无需登录、无需角色校验的接口。例如登录接口、验证码接口。超级管理员角色特殊角色拥有全部权限跳过权限校验。业务上要控制数量防止账号泄露风险。权限缓存用户登录后查询该用户所有角色再查出全部权限存入Redis。避免每次请求反复查数据库提升接口性能。PHP项目中RBAC权限缓存是高频优化点角色变更后需要清理对应用户的权限缓存。四、数据库表设计术语PHP后端落地RBAC0经典五表user 用户表用户账号、密码、基础信息role 角色表角色名称、角色描述、状态permission 权限表权限标识、权限名称、所属菜单、类型user_role 用户角色中间表user_id、role_id多对多role_permission 角色权限中间表role_id、permission_id多对多五、通俗类比RBAC就像公司的岗位制度用户 员工角色 岗位财务、人事、总监权限 办公室钥匙、系统操作权限员工不直接拿钥匙而是分配岗位岗位预先配好钥匙。员工换岗位只需要更换岗位不用逐个收回/发放钥匙。同一个人可以兼任多个岗位一个用户多个角色同一个岗位可以多个人担任。六、高频误区澄清❌ RBAC可以自动处理数据权限✅ 标准RBAC只解决功能权限能不能点按钮、调用接口。数据权限是额外扩展需要自己编码实现。❌ 权限校验放在前端就足够安全✅ 前端只是体验优化。恶意用户可以绕过前端直接请求接口后端接口必须做权限校验。❌ 一个用户只能分配一个角色✅ RBAC支持多角色。用户拥有的权限是所有角色权限的并集。❌ RBAC必须用五张表不能简化✅ 小型后台可以简化但标准模型是五表业务增长后简化表会难以维护。❌ 角色继承是RBAC0必备功能✅ RBAC0最常用版本没有角色继承继承属于RBAC1的增强能力。RBAC是PHP业务后台高频开发模块。在Hyperf、Laravel都有现成RBAC权限组件。同时RBAC的缓存设计会用到Redis权限校验逻辑需要理解接口、中间件。在十五五企业数字化项目中几乎每个管理平台都会落地RBAC。 RBAC的术语大全的庖丁解牛
根因业务系统OA、后台管理、ERP、企业数字化平台必然存在权限控制需求。最简单的权限写法直接给用户写死判断if($user_id 1) {允许操作}。这种硬编码方式用户一多、岗位变动代码改不停完全无法维护。RBACRole-Based Access Control基于角色的访问控制核心思想不给用户直接绑定权限中间增加一层「角色」做隔离。用户绑定角色角色绑定权限。当岗位变动只需要更换用户的角色不用修改权限本身也不用改代码。它是企业后台系统最通用的权限模型PHP开发管理后台几乎必用也是十五五数字化平台标准组件。核心一句话用户 ← 角色 → 权限角色作为中间桥梁解耦用户和权限。一、核心基础术语用户 User使用系统的人。账号主体比如管理员、财务、运营。一个用户可以分配多个角色。角色 Role岗位/身份的抽象例如超级管理员、财务、运营、普通查看员。角色是权限的集合载体。权限 Permission最小粒度的可操作点。分为两种功能权限、数据权限。功能权限按钮、接口、菜单例如新增订单、删除用户、查看菜单。数据权限能看到哪些业务数据例如只能看自己部门订单还是全公司订单。用户-角色关联 User-Role多对多关系。一个用户可以拥有多个角色同一个角色可以分配给多个用户。数据库一般单独一张中间表user_role存储。角色-权限关联 Role-Permission多对多关系。一个角色包含多条权限同一个权限可以归属多个角色。数据库中间表role_permission。二、RBAC的4个经典版本RBAC0 ~ RBAC3RBAC0基础版绝大多数后台用这个最基础模型用户、角色、权限两张多对多关联表。支持用户多角色角色多权限。日常PHP开发的后台权限基本都是RBAC0。没有角色继承、没有约束。RBAC1带角色继承在RBAC0基础上增加角色层级继承。例子总监角色自动继承下属主管角色全部权限。角色可以单向继承子角色拥有父角色权限。优点减少权限重复配置缺点层级复杂后权限不好排查。RBAC2带约束在RBAC0基础上增加业务约束规则互斥角色同一个用户不能同时拥有两个互斥角色。比如不能同时是“申请人”和“审批人”。基数约束某个角色最多只能分配给N个人。例如超级管理员最多2人。先决条件角色想要分配角色A必须先拥有角色B。RBAC3RBAC1RBAC2合并继承 约束是完整标准RBAC模型大型复杂企业系统才会使用中小型后台很少落地。三、扩展高频术语实际开发必遇到菜单权限权限的一种表现形式。控制左侧菜单是否展示。本质是权限前端根据后端返回的权限列表渲染菜单。误区菜单隐藏不等于接口安全。前端隐藏菜单直接调用接口依然能访问权限校验必须放在后端。按钮权限同一个页面不同角色看到不同按钮。例如普通员工只能查看管理员才有删除按钮。同样前端只是控制按钮显示后端接口必须二次校验。数据权限行级权限RBAC原生标准只定义功能权限。数据权限属于RBAC的扩展不属于标准RBAC。功能权限控制“能不能做这个操作”数据权限控制“能操作哪几条数据”。例子销售A只能看自己创建的客户销售经理可以看本部门全部客户。实现方案在SQL中自动追加数据范围条件。资源 Resource权限保护的目标对象。接口、页面、文件、数据表都叫资源。操作 Operation对资源的动作查看、新增、修改、删除。权限经常设计为「资源:操作」格式例如order:create、user:delete。这种字符串标识就是权限标识符PHP项目里非常常用。权限白名单无需登录、无需角色校验的接口。例如登录接口、验证码接口。超级管理员角色特殊角色拥有全部权限跳过权限校验。业务上要控制数量防止账号泄露风险。权限缓存用户登录后查询该用户所有角色再查出全部权限存入Redis。避免每次请求反复查数据库提升接口性能。PHP项目中RBAC权限缓存是高频优化点角色变更后需要清理对应用户的权限缓存。四、数据库表设计术语PHP后端落地RBAC0经典五表user 用户表用户账号、密码、基础信息role 角色表角色名称、角色描述、状态permission 权限表权限标识、权限名称、所属菜单、类型user_role 用户角色中间表user_id、role_id多对多role_permission 角色权限中间表role_id、permission_id多对多五、通俗类比RBAC就像公司的岗位制度用户 员工角色 岗位财务、人事、总监权限 办公室钥匙、系统操作权限员工不直接拿钥匙而是分配岗位岗位预先配好钥匙。员工换岗位只需要更换岗位不用逐个收回/发放钥匙。同一个人可以兼任多个岗位一个用户多个角色同一个岗位可以多个人担任。六、高频误区澄清❌ RBAC可以自动处理数据权限✅ 标准RBAC只解决功能权限能不能点按钮、调用接口。数据权限是额外扩展需要自己编码实现。❌ 权限校验放在前端就足够安全✅ 前端只是体验优化。恶意用户可以绕过前端直接请求接口后端接口必须做权限校验。❌ 一个用户只能分配一个角色✅ RBAC支持多角色。用户拥有的权限是所有角色权限的并集。❌ RBAC必须用五张表不能简化✅ 小型后台可以简化但标准模型是五表业务增长后简化表会难以维护。❌ 角色继承是RBAC0必备功能✅ RBAC0最常用版本没有角色继承继承属于RBAC1的增强能力。RBAC是PHP业务后台高频开发模块。在Hyperf、Laravel都有现成RBAC权限组件。同时RBAC的缓存设计会用到Redis权限校验逻辑需要理解接口、中间件。在十五五企业数字化项目中几乎每个管理平台都会落地RBAC。