ThinkPHP中间件不生效的主因是注册位置与绑定方式错误：全局中间件仅对应用级请求生效，控制器方法级拦截必须通过路由middleware参数绑定；Auth权限校验应使用think\facade\Auth而非直查数据库，并确保中间件函数每个分支都显式return。
中间件注册后不生效？检查 app/middleware.php 和路由绑定方式
ThinkPHP 的中间件是否起作用，和注册位置、绑定时机强相关。全局注册写在 app/middleware.php 里只对「应用级」请求生效，但控制器方法级拦截必须走路由定义——很多人漏掉这步，以为注册了就自动管所有控制器。
- 全局中间件适用于日志、跨域等通用逻辑，不参与权限校验的细粒度控制
- 控制器方法级拦截必须用
middleware路由参数：比如Route::get('admin/user', 'Admin/UserController@index')->middleware('auth'); - 若用资源路由（
Route::resource），需单独为每个操作指定中间件，它不会继承控制器类注解或构造函数里的设置 - 注意中间件类名是否带命名空间，
app/middleware.php中写的是类完整路径（如app\middleware\Auth），而路由里可简写为字符串'auth'（前提是已映射）
Auth 中间件里怎么获取当前用户并判断权限？别直接查数据库
权限校验的核心不是“能不能进”，而是“能进哪、能干啥”。硬编码 Db::table('user')->where(...) 在中间件里是典型反模式：既绕过系统认证态（如 think\facade\Auth），又重复初始化连接、丢失缓存。
- 优先用
think\facade\Auth获取登录态：Auth::check()判断是否登录，Auth::id()拿用户 ID，Auth::user()拿完整模型 - 权限字段建议存在用户模型里（如
role或permission_json），避免每次校验都连表查询；若用 RBAC，应预加载角色权限树到 Session 或 Redis - 不要在中间件里 throw 新异常，统一用
abort(403)或return redirect()->to('/login')，否则可能破坏框架异常处理流程 - 注意中间件执行顺序：权限中间件应放在日志、性能监控等中间件之后，但早于业务控制器执行
为什么 Auth::guest() 返回 false 却还是被拦住了？看中间件返回值
ThinkPHP 中间件函数必须显式 return，否则默认返回 null，框架会当成「中断请求」处理——这是最隐蔽的坑，尤其从 Laravel 迁移过来的人容易忽略。
- 正确写法：校验通过时
return $next($request)，不通过时return redirect()->to('/403')或abort(403) - 错误写法：
if (!Auth::check()) { abort(403); }——abort()抛异常没问题，但漏掉return $next($request)的分支，导致函数末尾隐式返回null - 调试技巧：在中间件开头加
trace('auth middleware hit');，确认是否真被执行；再看响应状态码是不是 500（说明中间件抛了未捕获异常）还是 403（说明逻辑走到 abort） - 如果用了闭包定义中间件（
function ($request, $next) { ... }），更要注意每个分支都有 return
控制器里用 __construct 做权限检查行不行？不行，会跳过中间件生命周期
有人想图省事，在控制器构造函数里调 Auth::check() 然后 abort，这看似能拦住请求，实则绕过了中间件机制本身。
- 构造函数执行时，
$request尚未经过中间件链（比如 CORS、Session 初始化等），Auth::user()可能为 null - 框架的中间件调度器无法感知这种手动拦截，导致日志、性能统计、异常上报等模块收不到完整上下文
- 更严重的是：如果该控制器被其他路由复用（比如 API 和 Web 共用一个控制器），权限逻辑就混在一起，没法按场景开关
- 真正需要差异化权限时，应该定义多个中间件（如
AdminAuth、ApiAuth），而不是在控制器里 if-else
权限中间件真正的复杂点不在写法，而在「权限数据怎么来」和「什么时候失效」——用户改了角色，Session 里没同步，Redis 缓存没清，或者多服务器间 Session 不一致，都会让中间件判断失准。这些细节比代码结构更值得花时间盯住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
