Webman可复用Laravel的Illuminate\Pipeline\Pipeline，需手动new实例并传入容器；处理器须实现handle($payload, $next)且调用$next，避免阻塞操作、异常吞没、资源泄漏及状态共享。
Webman 本身不内置 Pipeline 类，但你可以直接复用 Laravel 的 Illuminate\Pipeline\Pipeline，它完全兼容 Webman 的协程环境，且无需 HTTP 中间件上下文就能工作——只要你不依赖 Laravel 特有的容器绑定或 Facade。
怎么手动引入并初始化 Pipeline
Webman 没有 app() 容器自动解析，所以不能直接 app(Pipeline::class)。你得自己 new 实例，并显式传入容器（可选）或跳过依赖注入。
- 安装依赖：
composer require illuminate/pipeline - 创建处理器类时，必须实现
handle($payload, $next)方法，$next是 callable，必须调用才能进入下一步 - 不要在处理器里 throw Exception 后静默吞掉——
Pipeline默认不捕获异常，会中断整个链路 - 若需共享上下文（如请求 ID、用户信息），建议把它们作为
$payload的一部分传入，而不是依赖全局变量或静态属性
Pipeline 在 Webman 里容易踩的坑
最常见问题是协程安全和资源泄漏。Webman 运行在 Swoole 协程下，但 Pipeline 本身不感知协程，它只是顺序调用闭包或类方法。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 处理器中若用了阻塞操作（如
file_get_contents、未加go包裹的同步 Redis 调用），会卡住当前协程，拖慢整条链路 - 如果某个处理器返回了 null 或非预期类型，后续处理器可能因类型错误崩溃，而错误堆栈指向
$next($payload)，实际问题在上一步 - 别在处理器里做连接池初始化（比如 new Redis()），连接应在
onWorkerStart阶段完成；Pipeline 只负责逻辑编排，不负责资源生命周期管理 - Webman 的中间件机制和 Pipeline 是两套东西：前者作用于 HTTP 请求生命周期，后者是纯业务数据流——混用时注意执行时机，比如不要在 Pipeline 里再调一次
$request->withAttribute()
一个可用的用户注册 Pipeline 示例
假设你要在 Webman 控制器里跑注册后流程，目标是发邮件、写日志、触发事件，全部走协程安全方式：
use Illuminate\Pipeline\Pipeline;
use App\Pipelines\SendWelcomeEmail;
use App\Pipelines\LogUserRegistration;
use App\Pipelines\FireRegisteredEvent;
// $user 是刚创建的模型实例
$result = (new Pipeline(app())) // app() 可传 null，但建议传 Webman 的 Container 实例
->send($user)
->through([
SendWelcomeEmail::class,
LogUserRegistration::class,
FireRegisteredEvent::class,
])
->then(function ($user) {
return ['status' => 'ok', 'user_id' => $user->id];
});
注意：SendWelcomeEmail::handle() 内部必须用 co\run 或 go + Swoole\Coroutine\Http\Client 发邮件，不能用 Laravel 的 Mail::send()（默认同步阻塞）。
真正难的不是写 Pipeline，而是确保每个处理器都适配协程、不共享状态、不持有长生命周期资源——这些细节不会报错，但会在高并发时突然暴露。
