微服务中不能直接套用http中间件pipeline，因为其设计仅适配单次http请求-响应线性流程，无法支持跨grpc的context传递、阶段错误中断、异步fan-out/fan-in及checkpoint恢复；硬套http.handler模式会绑定responsewriter，导致无法复用于消息队列、定时任务或etl等场景，且易因goroutine未启动或channel未关闭引发死锁。
为什么微服务里不能直接套用HTTP中间件Pipeline
微服务内部的逻辑链路不是请求-响应的线性流程，而是跨服务、带状态、需错误传播与超时控制的数据流。Golang标准库的http.Handler和http.ServeMux那套middleware设计，只适用于单次HTTP请求上下文，无法承载：跨gRPC调用的context传递、阶段间错误中断、异步fan-out/fan-in、或checkpoint恢复。硬搬router.Use()模式会导致每个stage都绑死在http.ResponseWriter上，根本没法复用到消息队列消费、定时任务或ETL流水线中。
每个Stage必须独立goroutine + 显式关闭channel
常见死锁现象：fatal error: all goroutines are asleep - deadlock，根源是某个stage没启动goroutine，或忘了close(out)。比如一个地址校验服务作为pipeline中间stage，它接收，输出<code>chan *ValidatedAddress，但若写成同步调用：out ，上游发完就停，下游永远等不到数据。
- 每个stage函数体必须以
go func() { ... }()启动，哪怕只做简单转换 - 输入channel用
for v := range in安全读取，它自动处理ok == false退出 - 输出channel的
close(out)必须放在所有out 之后、goroutine退出前，绝不能靠<code>defer close(out) - 最下游stage（如写入ES或发kafka）不关任何channel，由调用方统一控制生命周期
错误和context怎么插进pipeline不卡死
原生channel不带错误语义，panic跨goroutine丢失，recover()又掩盖真实崩溃点。正确做法是把error和value打包进统一结构体，或引入额外chan error，但更推荐前者——减少channel数量，避免select分支爆炸。
- 定义
type Result[T any] struct { Value T; Err error }，全程走单channel - 每个stage签名必须含
ctx context.Context，且select第一case永远是case - 上游出错时，stage立即
out 并return，下游收到<code>Err != nil就停止消费 - 不要在stage里
log.Fatal或os.Exit——这会杀掉整个服务，不是中断当前pipeline
fan-out/fan-in并发控制容易漏掉的细节
比如订单服务需要并发调用3个外部校验API（实名、地址、风控），每个调用耗时不同，但必须等全部返回才聚合结果。手写merge函数时，常见问题是：goroutine泄漏、channel提前关闭、或漏掉某个输入channel的关闭信号。
-
fan-out：用for i := 0; i ，worker内必须用<code>for v := range in -
fan-in：合并函数要启动一个goroutine监听所有输入channel，用sync.WaitGroup计数，或更稳妥地——等每个输入channel都close后再close(out) - 并发数别硬编码，从配置读取，例如
config.ValidationConcurrency，上线后可动态调整 - 别用
time.Sleep模拟等待——它绕过context取消，超时后goroutine还在跑
微服务里的Pipeline不是语法糖，是状态、错误、背压、并发四者咬合的机械结构。最容易被忽略的是：每个stage的退出条件必须明确——是输入channel关闭？是context取消？还是第一个error到达？三者优先级不同，代码里得用select显式表达，而不是靠“应该会结束”这种假设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
