权限校验必须实时执行、避免中间件缓存；关联表需增加scope_type/scope_id支持数据级权限；Rule名须精确到路由或操作点如'admin/user/index'；应批量预加载规则ID以避免N+1查询。
权限判断逻辑必须绕过中间件缓存
ThinkPHP 默认的 Auth 或自定义中间件常把权限结果缓存进 Request 或 Session，导致角色变更后权限不生效。真实场景里，运营人员刚被分配「审核员」角色，却仍提示“无权限访问 /admin/review”，问题往往出在这儿。
实操建议：
- 所有权限校验逻辑（比如
checkPermission()）必须在控制器方法内实时执行，别依赖中间件里一次性算好的布尔值 - 避免用
$this->request->has('auth_checked')这类标记跳过校验；每次请求都查一次数据库或 Redis 缓存（带角色更新监听） - 如果用了
think-auth类扩展包，确认它没把role_id硬编码进 Session，而应通过Auth::getUser()->getRoles()动态获取
角色-权限关联表设计不能只靠 role_id + rule_id
很多项目建一张 role_rule 表，字段只有 role_id 和 rule_id，上线后才发现没法支持「部门级数据权限」或「某角色对订单 A 可编辑、对订单 B 仅可读」——这种细粒度控制需要上下文感知。
实操建议：
- 在关联表里加
scope_type（如'global'、'dept'、'user'）和scope_id字段，用于限定权限作用域 - 不要把「能否导出报表」和「能导出哪些部门的报表」混在同一个
rule里；前者走rule表，后者走关联表的scope_*字段 - 查询时用
where(['role_id' => $roleId, 'scope_type' => 'dept', 'scope_id' => $deptId])而非简单in匹配
Rule 规则名必须对应实际路由或操作点，而非功能模块名
错误写法：'order'、'user' —— 这类模糊规则名会导致后期无法精确回收权限。比如想取消某角色对「用户导出」的权限，但 'user' 规则还绑着「用户查看」「用户禁用」，一删全崩。
实操建议：
- Rule 名严格按 ThinkPHP 路由定义来，例如
'admin/user/index'、'api/v1/order/export'、'admin/goods/edit' - 涉及数据行级控制的操作，后缀加操作类型：
'admin/order/view:own'、'admin/order/delete:dept'，冒号后是策略标识，解析时再做分发 - 别用中文或空格命名规则，
$auth->check('编辑商品')在底层会转成不一致的键，查不到记录
RBAC 检查性能瓶颈常在 N+1 查询上
典型现象：用户打开后台首页就卡 2 秒，debug 显示执行了 47 次 SQL，其中 45 条是反复查 role_rule。这是因为每个菜单项、按钮都单独调了一次 Auth::check()，而默认实现没合并查询。
实操建议：
- 提前批量查出当前用户所有有效规则 ID，存入变量，后续所有
check()都从这个数组里 in_array 判断，而不是每次都查库 - 用
Db::name('role_rule')->where('role_id', 'in', $roleIds)->column('rule_id')一次取完，别在循环里查 - 如果用了视图菜单，把菜单配置里的
rule字段也预加载进来，渲染时直接比对，不触发额外 check 调用
最麻烦的不是设计多角色，而是当某个角色突然要叠加「临时工单处理权」又得即时生效——这时候 scope 控制和缓存穿透处理，比一开始的表结构还关键。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
