TP6 Auth类非RBAC，Auth::check()仅校验登录态和角色名，不查权限节点；根本原因是未调用Auth::setUser($uid)初始化权限缓存，导致总返回false。
TP6 的 Auth 类不是 RBAC，直接调用 Auth::check() 拦不住接口请求——它只校验登录态和角色名，不查权限节点。
Auth::check() 为什么总返回 false
根本原因不是权限写错了，而是没触发权限缓存初始化。TP6 自带的 Auth 类默认从 session('think_auth') 读缓存，但这个缓存只有在显式调用 Auth::setUser($uid) 后才生成。很多人在登录成功后跳转前忘了这一步，或者中间件执行时用户 session 已存在但缓存为空。
- 登录成功后必须立刻执行
Auth::setUser($uid)，不能延迟到跳转后或控制器里 - 若用了多应用（如
admin和api分开），Auth::check()默认查app应用下的规则，需显式传参：Auth::check('article/delete', $uid, 'admin') -
auth_rule表里的name必须严格匹配路由定义，比如路由是Route::get('admin/user/list', 'admin.UserController@list')，权限名只能是admin/user/list（斜杠分隔），不是admin.user.list或user_list
中间件里怎么真正拦截请求
别依赖 Auth::check() 做权限判断——它不是为 RBAC 设计的。真实拦截要自己查角色-权限映射，并且必须基于当前请求的路由规则名。
- 在中间件
handle()中，先用request()->rule()->getName()拿到当前路由名（如admin/user/edit） - 把这个名标准化成权限节点格式（例如转成
admin.user.edit，方便缓存键和匹配） - 查缓存：
cache('auth_rule_map_' . $roleId)，里面应存该角色所有可访问的rule_name集合（推荐 Redis 的 Set 结构） - 缓存未命中就 JOIN
auth_group_access → auth_rule查出权限列表并写入，过期时间设为 30 分钟；key 必须带$roleId，否则角色权限变更后其他用户缓存会误放行
权限节点命名和表结构最容易踩的坑
权限节点不是描述性文字，它是运行时被代码直接比对的字符串标识，错一个字符、大小写、分隔符都导致拦截失败。
立即学习“PHP免费学习笔记（深入）”；
-
auth_rule.name必须小写 + 点号或斜杠分隔（推荐点号），如admin.user.delete；避免中文、空格、下划线 - 不要给
auth_rule表加status、sort、remark字段——这些字段不参与鉴权，却会让 JOIN 变慢；状态控制统一走status字段，但查询时必须加WHERE status = 1 -
condition字段慎用：它会在每次鉴权时拼 SQL 执行，极易引发全表扫描或 SQL 注入；除非真需要「仅允许编辑自己创建的内容」这类动态条件，否则留空 - 角色-用户关系必须走
auth_group_access表，不能直接在用户表加role_id字段——否则一个用户只能属于一个角色
按钮能点但接口 403 却没日志
这是典型中间件没生效的表现。页面渲染靠前端权限判断（比如根据用户权限数组 show/hide 按钮），但后端接口没被中间件覆盖，请求直接进控制器执行了。
- 检查
app/middleware.php是否把自定义权限中间件注册到了全局或对应路由分组，且顺序在SessionInit之后 - 确认该接口路由没有被
except掉，或被其他中间件提前终止（比如 CORS 中间件抛异常中断流程） - 中间件里别只做静默跳转：如果
checkPermission()返回 false，必须显式throw new HttpException(403, 'Forbidden')或abort(403)，否则框架可能继续往下走
权限系统最麻烦的从来不是写代码，而是让所有人对「节点是什么」「谁决定能不能删」达成一致。一旦开始往 condition 里塞逻辑，或者在模板层用 if (checkPermission()) 控制按钮，就离线上事故不远了。
