ThinkPHP 8 的管道机制实为中间件链式执行模型，由 think\middleware\Pipeline 驱动，不支持 Laravel 风格的 send()->through()->then() 调用；中间件必须注册到应用层，输入固定为 think\Request 实例，返回值自动转为响应；业务流程应通过中间件+服务类组合实现，而非强行模拟管道。
ThinkPHP 8 的管道机制不是 Laravel 那套 Pipeline 类
ThinkPHP 8 没有 Illuminate\Pipeline\Pipeline，也不提供 send()->through()->then() 链式调用。它的“管道”是中间件（middleware）的执行模型，本质是请求生命周期中的**中间件链式调用**，由 think\middleware\Pipeline（注意命名空间不同）驱动，但对外不暴露为可直接实例化的工具类。
常见错误现象：Call to undefined function pipe()、试图在控制器里 new Pipeline() 报错、抄 Laravel 示例却始终不进中间件 handle 方法。
- 中间件必须注册到应用层（全局/路由/控制器级），不能临时拼装
- 没有
send($data)入口，输入始终是think\Request实例 - 无法像 Laravel 那样把任意数据（如订单对象）“推入”管道；TP8 管道只服务于 HTTP 请求流
- 中间件返回值会被自动转为响应（
think\Response），不能靠then()自定义终态逻辑
如何正确使用中间件实现“类管道”的流程控制
如果你需要对某个业务动作（比如创建订单）做多步校验或预处理，别硬套“管道”概念，改用中间件 + 服务类组合更稳妥。核心思路：把业务逻辑下沉，中间件只做拦截和流转控制。
- 定义一个中间件类（如
CheckOrderParams），在handle中校验参数合法性，非法则return json(['code' => 400])终止流程 - 在路由中绑定该中间件：
Route::post('order', 'OrderController@create')->middleware(CheckOrderParams::class) - 真正复杂的流程（如风控→锁库存→生成单号→写日志）应封装进服务类，控制器里顺序调用，而非塞进中间件链
- 若需复用某段逻辑（如“扣减库存并检查余额”），写成独立服务方法，中间件里只负责权限/状态前置判断
中间件链的执行顺序和中断行为容易被忽略
TP8 中间件按注册顺序依次执行，但**中断方式与 Laravel 不同**：中间件内不 return 响应，后续中间件仍会执行；只有显式 return 响应对象才会终止链路。
立即学习“PHP免费学习笔记（深入）”；
- 错误写法：
if (!$user) { throw new HttpException(401); }→ 异常会被异常处理器捕获，但中间件链继续往下走 - 正确写法：
if (!$user) { return json(['msg' => 'Unauthorized'], 401); }→ 立即终止，不再调用$next($request) - 漏掉
return $next($request)是高频 Bug：会导致后续中间件跳过，且无报错，仅响应为空或 500 - 调试技巧：在每个中间件开头加
Log::info('in '.__CLASS__)，观察日志是否连贯
想模拟 Laravel 风格的“数据流管道”？用闭包数组手动实现
TP8 不提供开箱即用的数据管道，但你可以用纯 PHP 实现轻量版，适用于非请求上下文的业务场景（如后台命令、定时任务）。
$pipeline = function ($input, array $stages) {
return array_reduce($stages, function ($carry, $stage) {
return $stage($carry);
}, $input);
};
$result = $pipeline($orderData, [
function ($data) { return array_merge($data, ['sn' => generateOrderSn()]); },
function ($data) { return $data['amount'] > 0 ? $data : throw new InvalidArgumentException('Amount must be positive'); },
function ($data) { return Order::create($data); }
]);
这种写法完全绕过框架机制，无依赖注入、无生命周期管理，适合简单流程；复杂场景建议上 DDD 分层或状态机，而不是强行“管道化”。
