中间件注册顺序决定执行顺序：PHP框架中，中间件按注册数组或链式调用的先后顺序执行，先注册者请求时先执行、响应时后执行，遵循洋葱模型；Laravel靠$middleware数组索引，ThinkPHP6依赖useMiddleware()调用次序。
中间件注册顺序决定执行顺序
PHP 框架（如 Laravel、ThinkPHP、Slim）里，中间件的执行顺序不是靠“修改某个配置项”动态调整的，而是由你 app()->middleware() 或 Route::middleware() 等注册时的**数组顺序**直接决定。先注册的中间件，请求时先执行，响应时后执行（即洋葱模型：外层进、内层出）。
常见错误是以为能通过中间件内部 return 或 flag 控制全局顺序——不能。顺序在路由绑定或应用启动时就固化了。
- 全局中间件按
$middleware数组索引从左到右执行（Laravel 的app/Http/Kernel.php中） - 路由组中间件按
->middleware([...])传入数组顺序叠加在全局之后 - 单个路由中间件优先级最高，但仍是按声明顺序插入到当前路由的中间件链中
Laravel 中改顺序：动数组，别动逻辑
想让 CheckAgeMiddleware 在 AuthMiddleware 之前运行？别在中间件里加 if 判断跳过，直接调换注册位置：
// app/Http/Kernel.php
protected $middleware = [
\App\Http\Middleware\CheckAgeMiddleware::class, // ← 放前面，请求时先触发
\App\Http\Middleware\AuthMiddleware::class, // ← 放后面，请求时后触发（但响应时先退出）
\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
];
注意：如果两个中间件都用了 return $next($request)，那么 CheckAgeMiddleware 的 handle() 会在 AuthMiddleware 的 handle() 之前进入，但在 AuthMiddleware 返回响应后才执行自己的“后置逻辑”（即 return 后的代码）。
立即学习“PHP免费学习笔记（深入）”；
ThinkPHP 6 的中间件顺序靠 useMiddleware() 链式调用顺序
TP6 不是数组注册，而是靠路由定义时的 useMiddleware() 调用次序：
// route/app.php
Route::get('admin', 'Admin/index')
->useMiddleware([\app\middleware\Auth::class]) // 先执行
->useMiddleware([\app\middleware\LogRequest::class]); // 后执行
这个链式调用顺序就是洋葱层叠顺序。想拦截更早，就把对应中间件往链开头挪；想确保它最后响应，就把它放链尾。
容易踩的坑：
- 全局中间件（
app/middleware.php）和路由中间件会合并，但路由中间件总在全局之后执行 -
useMiddleware()传字符串类名或对象实例均可，但顺序只看调用先后，不看类名字母序 - 中间件里 throw 异常会中断后续中间件执行，但已进入的中间件仍会走完自己的响应阶段（除非被 try/catch 拦截）
如何确认当前中间件实际执行顺序？
最可靠的方式不是查文档，而是打日志或断点。在每个中间件的 handle() 开头和结尾加调试输出：
public function handle($request, \Closure $next)
{
\Log::info('→ Enter: ' . static::class);
$response = $next($request);
\Log::info('← Exit: ' . static::class);
return $response;
}
发一次请求，看日志时间戳或顺序，就能 100% 确认真实执行流。很多“以为改了顺序却没生效”的问题，根源其实是缓存了路由或配置（Laravel 运行 php artisan config:clear && php artisan route:clear 再试）。
真正难的不是改顺序，而是理解“请求进”和“响应出”是两个反向路径；同一个中间件里，$next($request) 前的代码是“进”，后面的代码是“出”。这点漏掉，就容易在拦截逻辑里误判时机。
