RBAC在PHP中是可落地的工程方案，仅需4张表（users、roles、permissions、role_permissions），配合缓存加载、中间件校验和前后端协同，即可高效支撑大多数后台系统权限控制。
PHP网站做权限控制，RBAC不是概念玩具，而是可落地的工程方案。关键不在表多不多，而在结构稳、加载快、校验准——4张表起步，中间件拦截，缓存兜底，就能撑住大多数后台系统。
数据库结构：4张表够用，别提前加复杂度
最小可用RBAC结构就这4张表，不冗余、易维护、好扩展：
-
users：原用户表，只加一个
role_id字段（单角色场景）；或多建user_roles表（多角色更灵活） -
roles：字段
id、name，必须加UNIQUE(name)，比如"admin"、"editor" -
permissions：字段
id、code（如"post:create"、"user:read"），code必须设唯一索引 -
role_permissions：联合主键
(role_id, permission_id)，两个外键分别指向roles.id和permissions.id
别一上来就加 permission_group 或 role_hierarchy 表——90% 的内部系统根本用不到层级继承，反而增加出错概率和维护成本。
权限加载：一次查库，全程缓存
每次请求都 JOIN 4 张表查权限？QPS 上去数据库就卡死。核心原则是：登录后一次性加载，后续全走内存或缓存。
立即学习“PHP免费学习笔记（深入）”；
- 用户登录成功后，立即执行查询：通过
users → user_roles → role_permissions → permissions关联，SELECT 出所有code字符串，例如['post:create', 'post:read', 'user:export']</li> <li>存入 <code>$_SESSION['permissions']
（开发期快）或 Redis（生产推荐），key 建议为"user_perms_{$userId}_v2" - 角色/权限变更时，主动删除对应缓存 key，避免脏数据；不要依赖 session 过期自动清理
切忌把权限数组塞进 session 却不监听角色变更——用户被降权后，页面还能点半天才报错。
权限校验：封装 can() 方法 + 中间件统一拦截
硬编码 if (!in_array('order:delete', $perms)) die('no') 是最差实践。应该做到逻辑集中、调用轻量、拒绝明确。
- 封装一个全局
can($code)函数或 User 模型方法，内部只做数组查找：return in_array($code, $cachedPerms) - 写一个
CheckPermission中间件，在handle()中调用$request->user()->can($route->action['permission'] ?? null) - 路由定义时显式声明所需权限，例如：
->middleware('check.permission:post:publish')或在数组中加['permission' => 'post:publish'] - 拒绝时统一抛
HttpException(403)，不输出裸 die 或跳转错误页，方便日志追踪和前端处理
别在 Blade 模板里写 @if(auth()->user()->can('user:delete'))——权限判断必须前置到中间件或控制器，view 只负责渲染。
前后端协同：后端校验是底线，前端渲染是体验
权限控制不是后端做完就结束了。前端也需要配合，但前提是：后端校验不可绕过。
- 登录成功后，后端可通过接口返回用户全部权限码数组（如
/api/auth/me返回{"permissions": ["post:list", "post:create"]}） - 前端用该数组控制菜单显隐、按钮禁用/隐藏，提升用户体验，但所有关键操作仍需后端二次校验
- 权限码命名建议统一风格，如
模块:动作（user:delete、report:export），便于归类、搜索和策略扩展 - URL 路由路径（如
/admin/user/delete）和权限 code（如user:delete）不必强绑定，但建议保持语义一致，降低理解成本
不复杂但容易忽略。
