权限验证失败主因是中间件顺序错误、用户未注入请求或数据库查询为空；auth::check()在api中因禁用session失效，应改用jwt解析或显式指定guard；需确保认证中间件正确注册并调用withattribute注入用户，缓存权限时设过期时间并加主动失效钩子，响应403需按ajax或accept头统一格式。
权限验证失败，八成不是逻辑写错了，而是中间件没串对、用户没塞进请求、或者查库查到空了才报错。直接看这几个关键点。
Auth::check() 在 API 中间件里总返回 false
ThinkPHP 的 Auth::check() 默认走 session，但 API 场景通常禁用 session，只靠 Authorization 头里的 token。这时候调它等于白调——session 里压根没用户 ID。
- 改用
JWTAuth::parseToken()->authenticate()或手动解析 payload 拿sub字段查用户 - 确认 guard 是否显式指定：
Auth::guard('api')，别依赖config('auth.defaults.guard')默认值 - 检查中间件注册顺序：必须在
AllowCrossDomain之后、路由匹配之前执行，否则Authorization头可能被丢弃或覆盖 - 如果用了多环境配置，确认
config/jwt.php中的secret和生成 token 时用的一致（注意空格、换行、base64 解码合法性）
$request->getAttribute('user') 总是 null
这不是你漏写了认证逻辑，而是前置中间件根本没把用户对象塞进去。ThinkPHP 中间件默认不自动注入用户，$request->user() 或 $request->getAttribute('user') 都会为空。
- 确保已注册一个“认证中间件”，并在其中调用
$request = $request->withAttribute('user', $user) - 不要在
__construct()里尝试读$request->session()—— 构造阶段$request还没绑定 session - 避免硬编码控制器方法权限，改用
$request->url()->getPath()做路径级判断，比依赖不稳定路由别名更可靠 - 若
$request->route()返回null，先判空再调getName()，否则直接报Call to a member function getName() on null
权限变更后缓存不刷新，DB 又扛不住高频查询
每次请求都查 role_permission 表，QPS 上去 DB 就打满；全靠 Redis 缓存又怕运营后台改了权限，前端还拿着旧规则跑。
- 缓存设合理过期时间（如 10 分钟），同时加主动失效钩子：用户权限更新时
Cache::delete('permission:'.$role_id) - 缓存穿透时降级走本地配置文件
config/permissions.php，定义超级管理员可访问所有接口，避免 DB 挂了整个系统不可用 - 不要在中间件里直接查库，把权限加载逻辑封装成服务，支持从缓存、DB、配置三级 fallback
403 响应格式混乱，Ajax 和页面跳转都处理不好
同一个权限拦截点，既被浏览器表单提交触发，又被 fetch 调用触发，但返回 HTML 还是 JSON 完全取决于 Accept 头和是否带 X-Requested-With，不统一就容易前端解析失败。
- 用
$request->isAjax()判断是否为 Ajax 请求 - 检查
$request->header('accept')是否含application/json，优先按这个决定响应格式 - 避免硬写
return json(['code'=>403])，改用统一响应类封装，比如Response::forbidden()
最常被忽略的是中间件注册顺序和用户对象注入时机——不是代码没写，而是它根本没被执行到。调试时先打日志确认认证中间件是否运行、$request->getAttribute('user') 是否有值，再往下查权限逻辑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
