auth::check() 能稳定返回 true/false 是 thinkphp rbac 的核心，关键在于登录后调用 auth::setuser($uid) 初始化权限缓存，确保权限名与路由定义完全一致（如 admin/user/list），并避免 auth_rule 表冗余字段和 condition 滥用。
ThinkPHP 实现 RBAC 权限控制，核心不是堆表、不是写一堆 if 判断，而是让 Auth::check() 能稳定返回 true/false —— 其余都是围绕它展开的补救和优化。
Auth::check() 总是返回 false？先确认 Auth::setUser() 是否已调用
这是后台权限失效最常见原因：登录成功后没主动触发权限缓存初始化。TP6 的 Auth 类默认从 session('think_auth') 读缓存，而这个 session 不是自动写的。
- 登录逻辑里必须显式调用
Auth::setUser($uid)，不能只设session('user_id', $uid) - 如果用了多应用（如
admin和api分开），setUser()后要确保中间件里Auth::check()传对app参数，否则查的是默认app下的规则 - 别在中间件里用
$request->param('id')拼权限名（比如'article/edit/'.$id），应统一用路由定义的固定标识，如admin/article/edit
权限名 admin/user/list 和路由不匹配？严格对照 route/app.php 定义
Auth::check() 的第一个参数不是随便写的字符串，它必须与路由绑定的完整操作标识完全一致，包括斜杠分隔、大小写、前后缀。
- 若路由定义是
Route::get('admin/user/list', 'admin.UserController@list');，权限名只能是admin/user/list - 不能写成
admin.user.list、user_list或/admin/user/list（开头多斜杠） - 若用
name()显式命名了路由（如->name('user.list')），$request->rule()->getName()才会返回该 name；否则它可能返回空或控制器反射路径，这种情况下不要依赖它生成权限名
auth_rule 表字段滥用导致性能崩盘？只留 name/type，其余进缓存
很多人一建表就给 auth_rule 加 status、sort、remark，结果后期 JOIN 查询越来越慢——因为 TP 的权限判定只依赖 name 和 type 字段。
-
condition字段慎用：它会在每次Auth::check()时拼 SQL 执行，极易引发全表扫描或 SQL 注入，除非真需要动态条件（如“仅允许编辑自己创建的内容”），否则保持为空 -
pid必须为int类型且允许NULL或0，设成varchar会导致getMenuList()递归出错甚至无限循环 - 角色-用户关系必须走
auth_group_access表，别自建带start_time等字段的中间表——Auth类根本不识别这些字段
按钮显示了但点击 403？检查前端权限名是否和后端路由/规则对齐
页面能打开但按钮无响应、接口返回 403 却日志没报错，往往是因为前端渲染的权限标识和后端鉴权用的不一致。
- 前端按钮的 v-if 或 class 控制，应使用和服务端相同的权限名（如
admin/article/delete），而不是简写成article:delete或del_article - 删除接口被拦截却没抛异常？检查中间件里是否写了
if (!Auth::check(...)) { throw new HttpException(403); }——Auth::check()只返回布尔值，不自动 throw - 菜单节点在前端显示正常，但子项点不开？确认
auth_rule中对应节点的type是1（菜单）还是2（操作），别把操作节点误标为菜单
真正卡住人的从来不是「怎么配表」，而是 Auth::setUser() 忘调、权限名手抖少个斜杠、condition 字段悄悄拖垮查询——这些细节不盯死，再完整的 RBAC 设计也跑不起来。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
