PHP框架中间件作用及请求拦截详解

中间件本质是请求生命周期的钩子函数，嵌入在处理链中负责鉴权、日志等横切关注点；必须显式调用$next()继续流转，顺序、时机和返回值规则因框架而异，不可直接跨框架复用。

中间件本质是请求生命周期的钩子函数

PHP框架里的中间件不是独立服务，而是嵌入在请求处理链中的可复用函数。它在控制器执行前、后或出错时介入，不改变路由逻辑，只负责横切关注点——比如鉴权、日志、CORS头注入。Laravel、ThinkPHP、Slim 都用类似机制，但调用时机和参数传递略有差异。

常见错误是把它当“全局过滤器”滥用：比如在中间件里直接 exit 或 die，跳过后续中间件和控制器，导致日志未写、响应未格式化；更隐蔽的问题是中间件里修改了 $request 但没返回新实例（如 Laravel 的 withAttribute()），下游拿不到变更。

• 必须显式调用 $next($request)（或等价方法）才能继续流转，漏掉就中断整个链
• 中间件顺序很重要：认证中间件要放在日志中间件之后，否则未登录请求也记了日志
• 别在中间件里做耗时操作（如查库、远程调用），除非明确需要阻塞——否则考虑改用事件或队列

Laravel 中间件注册与参数传递

Laravel 的中间件分全局、分组、单路由三类注册方式，核心区别在于 app/Http/Kernel.php 里的数组位置：$middleware 全局生效，$middlewareGroups 绑定到 web 或 api 等分组，Route::middleware() 只对当前路由生效。

传参只能靠 URI 段或查询参数，中间件本身不支持函数式传参（如 throttle:60,1 是字符串解析，不是 PHP 参数）。自定义中间件接收参数需手动从 $request->route() 或 $request->query() 提取。

• php artisan make:middleware CheckAge 生成基础模板，重点看 handle() 方法签名
• 若需依赖注入（如 UserService），直接写在 handle() 参数里，容器自动解析
• 不要在 __construct() 里做初始化逻辑，构造函数在应用启动时就执行，无法访问请求上下文

ThinkPHP 中间件执行时机与终止控制

ThinkPHP 的中间件默认在控制器前执行，但可通过 return $next->handle($request) 控制是否继续。关键差异在于：TP 允许中间件返回 Response 实例提前结束请求，而 Laravel 要求始终调用 $next 否则报错。

高频踩坑是混淆 before 和 after 场景。比如记录响应时间，必须用 after 类型中间件（TP 支持 App\Middleware\Timing::class => ['type' => 'after']），否则拿不到实际耗时；又比如修改响应头，要在 after 阶段操作，before 阶段的 $response 还没生成。

• TP 中间件类必须实现 handle() 方法，返回值决定是否放行：null 或 Response 对象
• 多个中间件按注册顺序正向执行，但 after 类型会逆序触发（类似洋葱模型外层）
• 调试时可用 trace() 打点，但别在生产环境开启，避免影响性能

跨框架中间件复用的现实约束

别指望把 Laravel 的中间件直接搬到 ThinkPHP 里用。虽然都叫“中间件”，但接口契约完全不同：Laravel 要求返回 Response 或调用 $next，TP 接受 null、Response 或 Json；PSR-15 标准虽存在，但各框架实现程度不一，Slim 支持完整 PSR-15，Laravel 是兼容层封装，TP 则基本自研。

真正能复用的是业务逻辑本身。比如“JWT 验证”功能，可抽成独立类 JwtAuthenticator，再分别适配到各框架中间件中调用。硬搬代码只会陷入参数名不一致（$request vs $req）、异常处理方式不同（Laravel 用 abort()，TP 用 throw new HttpException()）的泥潭。

• 优先封装为无框架依赖的服务类，中间件只做胶水层
• 注意 PSR-7 Request/Response 对象的不可变性：修改后必须返回新实例，原对象不会变
• 测试中间件别只测单个，要验证整条链的顺序、中断行为、异常穿透是否符合预期

实际项目里，最易被忽略的是中间件的错误捕获边界——它不自动包裹控制器异常，除非你显式 try/catch 并返回错误响应。这点在 API 服务中尤其关键，否则 500 错误会直接暴露堆栈。