中间件不是越多越好，需精简并明确每层不可替代性；注册位置决定作用范围与性能，全局中间件仅放全站必需项，路由中间件按需绑定；handle()中禁用耗时操作；优先分组复用而非重复声明；顺序错误比缺失更危险，须严格遵循依赖关系。
中间件不是越多越好，加得随意反而拖慢请求、掩盖逻辑、引发顺序冲突。精简的核心不是删代码，而是明确每层中间件的不可替代性。
中间件注册位置决定作用范围和性能开销
全局中间件（$middleware）会拦截每个请求，哪怕只是访问 /robots.txt 或健康检查接口。实际项目中，90% 的中间件不该放这里。
- 只把真正全站必需的放
app/Http/Kernel.php的$middleware数组里，比如\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class、CSRF 验证（仅 web 组）、Session 启动（仅 web 组） -
$routeMiddleware是更安全的选择：按需绑定，不影响无关路由。例如权限校验中间件'can'、自定义的'throttle:api'，都该走这条路 - 避免在
$middlewareGroups['web']里塞业务逻辑中间件——它默认覆盖所有 web 路由，包括登录页、静态资源路由，容易造成重复执行或提前拦截
handle() 方法里别做耗时操作
中间件的 handle() 方法是同步阻塞执行的，任何 I/O 或复杂计算都会卡住整个请求链。
- 禁止在
handle()里调用DB::table()->get()、file_get_contents()、远程 API 请求等 - 日志记录尽量用异步驱动（如
stack+redis或papertrail），而不是直接Log::info() - 如果必须查数据库（比如白名单 IP 校验），确保字段有索引，且用
whereExists()或缓存兜底，避免全表扫描 - 不要在
handle()中 dump、dd、sleep()—— 这些只该出现在调试阶段，上线前必须清理
用中间件分组代替重复绑定
路由文件里反复写 ->middleware(['auth', 'can:view-posts', 'log.request']) 不仅冗余，还容易漏掉或错序。
- 优先用
Route::group()统一挂载：Route::middleware(['auth', 'can:view-posts'])->group(function () { Route::get('/posts', [PostController::class, 'index']); Route::get('/posts/{id}', [PostController::class, 'show']); }); - 对需要排除某些动作的场景（比如登录页不需要 auth），用控制器构造函数的
except()更清晰：public function __construct() { $this->middleware('auth')->except(['login', 'store']); } - 避免给单个路由叠加 4 个以上中间件——这时该考虑是否逻辑耦合过重，比如把参数校验、权限判断、限流合并成一个语义明确的中间件（如
'validate-and-authorize'），而不是堆砌
中间件顺序错误比没加更危险
Laravel 按数组顺序逐层执行中间件，一旦某层返回响应（如重定向、403），后续全部跳过。顺序错乱会导致 auth 失效、session 未启动就访问用户数据、CSRF 在 session 前校验失败等静默错误。
- 必须保证
\Illuminate\Session\Middleware\StartSession::class在依赖 session 的中间件（如auth）之前 -
\Illuminate\Auth\Middleware\Authenticate::class应在\App\Http\Middleware\CheckPermission::class之前，否则权限中间件拿不到Auth::user() - 自定义中间件若需修改请求（如添加 header、解析 token），应放在认证类之前；若需基于认证结果决策（如记录操作日志），则放其后
- 不确定顺序时，查看
app/Http/Kernel.php的$middlewarePriority数组——Laravel 内置中间件的执行优先级已在此明确定义，你的中间件应主动对齐
精简不是删减，而是让每一层中间件都有明确职责、最小作用域和可控执行时机。最容易被忽略的是中间件之间的隐式依赖——比如某个中间件悄悄读了 session，却没声明它依赖 StartSession，上线后只在高并发下偶发报错。
