怎样在 PHP 中实现简单的权限控制系统_基于 RBAC 模型设计数据库-php教程-PHP中文网

rbac最小可用数据库结构为4张表：users（用户）、roles（角色，name加unique）、permissions（权限，code加unique）、role_permissions（联合主键role_id+permission_id，双外键）。

怎样在 php 中实现简单的权限控制系统_基于 rbac 模型设计数据库

直接上最小可用结构，4 张表够用，别一上来就加 permission_group 或 role_hierarchy——90% 的内部系统根本用不到层级继承。

常见错误是把 permissions 表设计成「字符串权限码」（如 "user:delete"）却没加唯一索引，导致重复插入、查重慢；或者把 role_permissions 设计成 JSON 字段，彻底放弃外键约束和查询效率。

roles：主键 id，字段 name（如 "admin"、"editor"），加 UNIQUE(name)
permissions：主键 id，字段 code（如 "post:create"、"order:read"），必须加 UNIQUE(code)
role_permissions：联合主键 (role_id, permission_id)，两个外键分别指向 roles.id 和 permissions.id
users：原表加一个 role_id 外键（单角色场景），或另建 user_roles 表（多角色场景）

别在每次请求都查 4 张表。核心原则：权限判定必须走缓存，且缓存 key 要包含 role_id 或 user_id + 当前时间戳（用于手动失效）。

典型错误是写个 getPermissionsByUserId($userId) 每次都执行 JOIN 查询，QPS 上去就拖垮数据库；更糟的是把权限数组塞进 session，但用户角色变更后 session 不自动更新。

推荐做法：查一次 role_permissions 关联 permissions.code，返回纯数组，例如 ['post:create', 'post:read']
缓存用 apcu_cache 或 Redis，key 形如 "user_perms_{$userId}_v2"，失效策略设为「角色变更时删 key」
如果用 Laravel，直接在 User 模型里加 permissions() 关联，但务必加 ->pluck('code') 避免加载整行对象

硬编码 if (!in_array('post:edit', $userPerms)) { die('no'); } 是最差实践——无法复用、无法统一拦截、日志难追踪。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

真正轻量的做法是封装一个 can($permissionCode) 方法，内部只做数组查找（不是查库），并配合中间件统一处理拒绝逻辑。

中间件里调用 $request->user()->can('post:delete')，返回 false 就 throw HttpException(403)
can() 方法应提前把用户所有权限 code 加载进内存（从缓存取），避免运行时查库
别把权限校验写在 view 层（比如 Blade 里 @if(auth()->user()->can('user:export'))...），view 应只负责渲染，权限逻辑下沉
URL 路由和权限 code 建议保持映射习惯，例如 POST /api/posts → "post:create"，方便后期自动化校验

用 "user" 这种模糊码会迅速失控：你分不清是「查看用户列表」还是「编辑用户资料」，更没法控制「只读」和「可删」的差异。RBAC 的本质是控制「对什么做啥」，不是「能进哪个菜单」。

线上出过问题：运营同学反馈「能进用户页但点删除按钮没反应」，查发现前端按钮没做权限隐藏，后端接口又没校验 "user:delete"，只校验了 "user"——结果是功能开着，但关键操作裸奔。

强制采用 "{resource}:{action}" 格式，resource 小写中划线（order_item），action 限用 read/create/update/delete/export
避免动词泛化：不用 "manage"、"access"、"view"（歧义大），"view" 改为 "read"，"edit" 改为 "update"
特殊场景如「审核订单」，不要造新 action，拆成 "order:update_status" 并在业务逻辑里判断状态流转是否合法