因为Laravel用array_reduce配合array_reverse构建闭包链，使中间件按注册顺序从前到后处理请求、从后到前处理响应，天然形成洋葱模型双向流转。
中间件执行顺序为什么是“倒着组装”的？
因为 array_reduce 拿的是反转后的中间件数组，从右往左包裹闭包。比如你注册了 [$a, $b, $c]，实际执行链是 $a($b($c($destination)))，但请求流是：$a（前置）→ $b（前置）→ $c（前置）→ $destination → $c（后置）→ $b（后置）→ $a（后置）。这正是洋葱模型的根源，不是靠循环硬写，而是靠闭包嵌套天然形成双向流转。
常见错误现象：dd() 放在中间件里没触发、或只触发一次，往往是因为误以为中间件是线性顺序执行，忽略了 $next($request) 才是进入下一层的关键跳转点。
- 不要在中间件里直接
return response()后忘了调用$next()，否则后续中间件和控制器全被跳过 -
through()传入的数组顺序 = 你希望的“最外层 → 最内层”顺序，Laravel 内部会自动反转来构建闭包链 - 自定义 Pipeline 复用时，如果手动调用
array_reduce却忘了array_reverse，会导致执行顺序完全颠倒
handle() 方法里 $next($request) 到底返回什么？
它返回的是下游整个管道处理完后的 Illuminate\Http\Response 实例（或控制器返回的任意可响应内容），不是下一个中间件本身。也就是说，$next 是一个已经组装好的、包含所有剩余中间件 + 目标逻辑的闭包，你调它，就等于把当前请求“推”进整条管道的剩余部分。
使用场景举例：权限中间件中，检查失败直接 return redirect('/login')；成功则必须 return $next($request)，否则请求卡死在当前层。
立即学习“PHP免费学习笔记（深入）”；
- 不能把
$next当作函数名去调用（如$next->handle()），它是运行时动态生成的 Closure - 若中间件需修改响应头或内容，必须在
$next($request)返回后操作，否则会被后续中间件覆盖 - 注意：Laravel 5.5+ 中
$next闭包已绑定好$passable和后续逻辑，无需再传参
为什么 terminate() 不走 Pipeline？
terminate() 是独立于主管道之外的异步清理钩子，由 Kernel::terminate() 统一触发，不参与 array_reduce 构建的闭包链。它的存在意义是解耦长耗时操作（如写日志、释放资源），避免阻塞响应返回。
容易踩的坑：在 handle() 里做 DB 查询，又在 terminate() 里试图复用同一个 Query Builder 实例——此时连接可能已关闭或事务已提交，报错 PDOException: There is no active transaction。
-
terminate()接收的是原始$request和最终$response，无法访问中间件局部变量 - 只有显式注册了
shouldReport()或实现了terminate()的中间件才会被调用 - 别指望它能拦截或修改响应体，它纯属“事后收尾”，不是管道一部分
自定义 Pipeline 复用中间件时参数怎么透传？
标准中间件签名是 handle($request, Closure $next)，但如果你用 Illuminate\Pipeline\Pipeline 处理非 HTTP 场景（比如任务预处理、数据清洗），$passable 可以是任意类型——数组、对象、甚至字符串。关键在于所有中间件必须约定好输入/输出结构。
性能影响：每次 send()->through()->then() 都会重建闭包链，高频调用时建议复用 Pipeline 实例，或提前编译好固定流程。
- 不要在中间件里依赖 Laravel 容器单例状态（如
app('cache')），除非确认该 Pipeline 在 request 生命周期内执行 - 若中间件需访问容器，用
$this->container->make(...)而非app()，避免闭包绑定时捕获错误实例 - 参数穿透失败最常见的原因是：某个中间件没
return，导致下游接收null
carry() 闭包里对非 Closure 类型中间件的解析逻辑——它会尝试从容器解析类并调用 handle()，但如果你传了个没实现该方法的类，错误提示只会说 Call to undefined method，不会告诉你具体哪个中间件出问题。 
