php实现rbac需手动建4张最小表（users、roles、permissions、role_permissions），权限码用如“post:edit”的字符串格式，登录后缓存至redis/session并设版本号防stale，校验时走用户→角色→权限链路，禁用硬编码角色名判断。
PHP 本身不提供 RBAC 内置支持，所有逻辑必须手动实现；用错表结构、跳过角色层、每次请求查库，这三类错误占权限失效问题的 80% 以上。
怎么建表才不会在权限校验时丢权限
最小可用结构是 4 张表：users、roles、permissions、role_permissions。别一上来就加 user_roles 或 permission_groups——单角色场景下 users 表直接加 role_id 外键更轻量；多角色才需要独立的 user_roles 表。
关键约束必须加：
-
permissions.code字段必须设UNIQUE，否则相同权限码重复插入后，in_array('post:edit', $perms)可能误判 -
role_permissions必须用联合主键(role_id, permission_id)，且两个字段都设外键，禁用 JSON 字段存权限列表 - roles.name 建
UNIQUE索引，避免「admin」和「Admin」被当成两个角色
为什么不能用 if (user->role === 'admin') 做判断
角色名只是语义标识，真正决定访问能力的是该角色关联的权限节点（如 user:delete）。硬编码角色名会导致两种典型翻车：
- 管理员角色没配
config:write，但代码里写了if ($role === 'admin') allow()，结果开了后门 - 运营临时给 editor 角色加了
order:refund，但控制器里没改判断逻辑，功能不可用
正确路径永远是：用户 → 查其角色 → 查角色对应的所有 permission_code → 缓存数组 → in_array($need, $cached)。
登录后权限怎么缓存才不 stale
缓存不是为了省一次查询，而是让权限判定稳定在 O(1)。常见错误是把权限塞进 $_SESSION['permissions'] 后再也不更新——用户在后台改了角色，session 还是旧的。
- 缓存 key 推荐用
"user_perms_{$uid}_v2"，版本号 v2 用于手动失效（比如角色变更后删掉该 key） - 优先用 Redis 而非 APCu，便于跨机器共享、设置 TTL（如 60 秒），并配合钩子清除：
DEL user_perms_*_v2或精确删user_perms_123_v2 - 不要在中间件里调
Auth::check('admin/user/edit', $uid)却不先确保Auth::setUser($uid)已执行——TP6 的 Auth 类依赖 session 里的think_auth，漏这步永远返回 false
中间件里怎么写权限拦截才不散落在各处
把 if (!in_array(...)) die() 塞进每个控制器，等于把权限逻辑焊死在业务层。真实项目里，90% 的权限问题出在拦截点太晚或太碎。
- 封装统一
can($code)方法，内部只做数组查找，不查库、不 JOIN - 中间件中调用前必须确保权限已加载：例如 Webman + Casbin 场景下，
$enforcer->enforce($sub, $obj, $act)是唯一入口；原生 PHP 则检查$_SESSION['permissions']是否存在，不存在则触发loadUserPermissions($uid) - 拒绝响应必须显式抛异常或
http_response_code(403)并exit，别只 echo 'no'——前端可能收不到状态码，日志也难追踪
权限码设计本身是个隐性陷阱：用 post:edit 而不用 12 或 编辑文章，是为了让字符串可读、可分组、可缓存、可跨系统同步；一旦开始混用 ID 或中文，后续加 ABAC 规则或对接前端权限组件就会卡住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
