RBAC最小可用数据库结构为4张表：users（用户）、roles（角色，name加UNIQUE）、permissions（权限，code加UNIQUE）、role_permissions（联合主键role_id+permission_id，双外键）。
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表（多角色场景）
PHP 里怎么快速查用户有哪些权限
别在每次请求都查 4 张表。核心原则：权限判定必须走缓存，且缓存 key 要包含 role_id 或 user_id + 当前时间戳（用于手动失效）。
典型错误是写个 getPermissionsByUserId($userId) 每次都执行 JOIN 查询，QPS 上去就拖垮数据库；更糟的是把权限数组塞进 session，但用户角色变更后 session 不自动更新。
立即学习“PHP免费学习笔记（深入）”；
- 推荐做法：查一次
role_permissions关联permissions.code，返回纯数组，例如['post:create', 'post:read'] - 缓存用
apcu_cache或 Redis，key 形如"user_perms_{$userId}_v2"，失效策略设为「角色变更时删 key」 - 如果用 Laravel，直接在
User模型里加permissions()关联，但务必加->pluck('code')避免加载整行对象
如何在控制器里做权限校验而不写满 if
硬编码 if (!in_array('post:edit', $userPerms)) { die('no'); } 是最差实践——无法复用、无法统一拦截、日志难追踪。
真正轻量的做法是封装一个 can($permissionCode) 方法，内部只做数组查找（不是查库），并配合中间件统一处理拒绝逻辑。
- 中间件里调用
$request->user()->can('post:delete')，返回 false 就 throwHttpException(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"并在业务逻辑里判断状态流转是否合法
权限系统最难的不是建表或写 can()，而是让所有人——产品、前端、后端——对每个权限码的含义达成一致，并在接口文档、菜单配置、按钮逻辑里严格对齐。一旦松动，后面只能靠日志倒查补漏。
