Auth类不能直接做RBAC资源级控制，因其仅验证用户是否具备某规则权限，不支持“角色→资源→操作”三层粒度；需手动配置auth_rule表（type=1）、维护auth_role_rule关联、标准化资源标识并缓存权限数据。
为什么 Auth 类不能直接做 RBAC 资源级控制
ThinkPHP 自带的 Auth 类本质是基于规则（rule）的权限验证，它只判断「用户是否能执行某条规则」，并不天然支持「角色 → 资源 → 操作」三层粒度。比如你没法直接表达「运营角色只能访问 /admin/article 的 index 和 edit，但不能删」这种组合。
常见错误现象：Auth::check() 总返回 false，或权限放行后所有接口都通——根本原因是把资源路径（如 admin/article/delete）当成了规则名，但没在数据库里配置对应规则，也没绑定到角色。
- 必须手动把每个「控制器/方法」或「路由标识」作为一条
auth_rule记录存入数据库 -
auth_rule表中type字段得设为1（表示权限规则），不能混用0（菜单） - 角色和规则之间靠
auth_role_rule关联表连接，漏建这张表或字段类型不匹配（比如role_id是字符串却用了 int）会导致关联失效
如何让 rbac_check_access 支持 HTTP 方法 + 路由变量
原生 Auth::check() 只认固定规则名，但真实场景中常要区分 GET /api/user/1（查看）和 DELETE /api/user/1（删除），甚至要过滤 ID 范围。这时候得重写校验入口。
推荐做法：在中间件或基类控制器里，把当前请求解析成标准资源标识，例如 user:read:1 或 article:delete，再传给自定义检查函数。
立即学习“PHP免费学习笔记（深入）”；
- 用
Request::url()+Request::method()拼出唯一 key，避免把POST /user和GET /user当成同一权限 - 路由变量（如
:id）需提前提取并标准化，否则user:delete:123和user:delete:456得配两条规则——应统一为user:delete:id - 别在每次请求里查数据库比对权限，把角色拥有的全部资源规则缓存成数组，用
in_array()判断，性能差一个数量级
AuthRule 表设计哪些字段不能少
很多团队照搬旧版 ThinkPHP 示例，只建了 id、name、title 三个字段，结果发现无法支持动态资源控制。
关键缺失字段直接影响扩展性：
-
status：必须有，用于临时禁用某条规则而不删数据（比如下线某个接口的权限） -
condition：字符串字段，存 PHP 条件表达式（如"$data['user_type'] == 'vip'"），Auth 类会eval它——注意开启前要严格过滤输入，否则 RCE -
pid和level：不是可选，而是决定规则继承关系的基础。没有它们，就做不到「管理员角色自动拥有编辑员角色的所有资源」 - 别用
name存完整 URL，应拆成module、controller、action三个字段，方便按模块批量授权
中间件里调用 Auth::check() 为什么总失败
最常见原因：Auth 实例初始化时没传入用户 ID，或用户登录态没写进 session 的默认 key（think_user）里。
ThinkPHP 6+ 的 Auth 默认从 Session::get('user_id') 取值，而多数项目用的是 member_id 或 admin_id。
- 要么改 Session key 名称，要么在中间件里手动传参：
Auth::check($ruleName, $userId) - 别在构造函数里初始化 Auth，因为中间件执行时容器可能还没注入 Request 对象，
$this->request是 null - 如果用了多应用（如 admin 和 api 分开），确保
auth配置里的auth_group_access表前缀跟当前应用一致，否则查不到角色归属
复杂点在于资源标识的抽象程度——太粗（只到控制器层）管不住具体操作，太细（每个 ID 都单独配）运维成本爆炸。真正落地时，80% 的权限需求靠「模块+操作+有限白名单条件」就能覆盖，硬要支持全动态表达式反而增加不可控风险。
