collection::pipe()是laravel 9.2+新增的集合实例方法，仅接收一个闭包，将整个集合传入并返回其执行结果，适用于单次封装调用（如日志、调试），不支持链式流转或中间件式处理，与pipeline模式完全无关。
直接说结论：Laravel 没有 pipe() 这个全局函数或集合方法，Collection::pipe() 是 Laravel 9.2+ 新增的实例方法，不是管道模式（Pipeline）的替代品，两者用途、签名和行为完全不同——混淆它们是线上 bug 最常见的根源之一。
Collection::pipe() 是什么，什么时候用
Collection::pipe() 是集合实例上的一个**单次透传方法**，只接收一个闭包，把整个集合对象作为参数传进去，闭包返回什么，pipe() 就返回什么。它不串联、不中断、不支持中间件式流转，纯粹是“把集合塞进一个函数里跑一次”。
- 适用场景：快速做一次封装调用，比如日志记录、调试打印、临时转换格式
- 错误现象：
$collection->pipe(fn($c) => $c->map(...))写成$collection->pipe(...)->map(...)链式调用 → 报错，因为pipe()返回的是闭包执行结果，不保证还是 Collection - 参数差异：只传一个参数（整个集合），不像 Pipeline 的每个中间件都必须接收
$passable和$next - 性能影响：无额外开销，就是一次函数调用；但若闭包里做了耗时操作（如 DB 查询），会阻塞整个流程
示例：
$users = User::cursor()->collect();
$result = $users->pipe(function ($collection) {
\Log::info('Processing '. $collection->count() .' users');
return $collection->filter(fn($u) => $u->is_active);
});
Pipeline::send()->through()->then() 不能和 Collection::pipe() 混用
很多人想“用 Collection 管道流式处理数据”，于是把 Collection 当作 send() 的输入，再传一堆闭包进去——这能跑通，但语义错、风险高。
- 常见错误：在
through()里写function ($collection, $next) { return $next($collection->map(...)); }，看似流式，实则破坏了 Pipeline 的契约：每个中间件必须显式调用$next($passable)，而$collection->map()返回新集合，类型没变，但后续中间件若依赖原始集合的元信息（如 key、游标状态），就会静默出错 - 兼容性问题：Laravel 9.2+ 的
Collection::pipe()返回值类型由闭包决定；Pipeline 的then()回调拿到的却是最后一个中间件的返回值——两者生命周期、错误捕获、调试支持完全隔离 - 调试困难：Collection 方法链断点容易打，Pipeline 中间件里
dd()会中断整个链，且无法看到$next的真实结构
真正需要“集合流式处理”时，该选哪个
判断依据就一条：你是否需要「可中断、可复用、可注入依赖、带异常传播」的多步处理？
- 不需要——只是对集合做几次转换（filter/map/flatMap），直接用 Collection 原生方法，或加一层
pipe()封装即可 - 需要——比如“查用户 → 校验权限 → 加载关联 → 转 DTO → 推送事件”，必须用
Illuminate\Pipeline\Pipeline，且每个中间件要明确设计输入输出类型（例如统一收Collection，统一返Collection） - 容易踩的坑：在 Pipeline 中间件里调用
$collection->each()并修改内部模型属性，却不return $next($collection)→ 流程静默终止，then()拿到 null - 关键提醒：Pipeline 不校验类型，
send()传 Collection，中间件 return 数组，下一个中间件收到数组却还当 Collection 调map()→ 直接报Call to undefined method map()
最常被忽略的一点：Pipeline 的中间件之间没有类型契约，$passable 是什么，全靠你手动保证。Collection 方法链天然保类型，Pipeline 不保——这不是缺陷，是设计取舍。用错地方，比写错逻辑更难排查。
