go中间件本质是同步函数嵌套链，非真正pipeline：必须为func(http.handler) http.handler类型，显式调用next.servehttp实现洋葱模型，数据传递依赖context.context，组合顺序为m1→m2→m3→handler，panic需外层recover。
Go 里没有“高阶函数管道模式”这种东西——func(f func(int) int) func(int) int 这类函数组合不是 pipeline，它不并发、不流式、不处理 channel，只是同步调用链。真要实现中间件式 pipeline（比如 HTTP handler 链、日志过滤链），必须用 goroutine + channel；否则就是伪 pipeline，一卡全卡死。
为什么用高阶函数拼 http.HandlerFunc 不算 pipeline
常见误区是把 middleware1(middleware2(handler)) 当成 pipeline。它本质是函数嵌套：每次请求进来，按顺序同步执行每个 middleware 的 next.ServeHTTP，没有并发、没有数据流、没有背压。它解决的是责任链式拦截，不是数据流处理。
- 无 goroutine：所有逻辑在同一个协程跑，无法并行处理多个请求阶段
- 无 channel：不传递数据流，只传
http.ResponseWriter和*http.Request指针，没法做扇入/扇出或错误广播 - 关闭时机不可控：中间件无法统一响应中断（比如超时后立刻停掉后续日志 enrich 或 metrics 上报）
gen → filter → transform 这类才叫真 pipeline
真正的 pipeline 必须每个 stage 启一个 goroutine，用 channel 串起来。例如：
func gen(nums []int) func filter(in <p>func transform(in </p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig"><img src="https://img.php.cn/upload/skill/000/000/081/179215391842073.jpg" alt="Golang Uber Dig" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig" class="overflowclass">Golang Uber Dig</a> <p class="overflowclass">使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等</p> </div> <a rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 每个函数返回
，但内部都显式 <code>go func()启动协程 - 输入 channel 必须由上游关闭，下游用
for v := range in安全读取 - 不能在函数体里直接
close(out)，必须放在 goroutine 内部、所有发送完成后
想让中间件有 pipeline 特性？得加 channel 和 context
如果硬要在 HTTP 中间件里引入 pipeline 思维（比如把请求 body 解析、字段校验、权限检查拆成异步 stage），必须放弃纯高阶函数写法，改用：
- 每个 stage 接收
context.Context和输入 channel（如） - 每个 stage 自己启动 goroutine，往输出 channel 发送结果或 error
- 用
select统一监听ctx.Done()、输入 channel、错误 channel - 错误不能靠 panic/recover 传播，必须走单个
errCh ，且其他 stage 一收到就 <code>return，不再发数据
否则你写的“pipeline”只是语法糖，运行时还是线性阻塞，一 stage 卡住，整条链挂死。
最易被忽略的点：channel 关闭时机永远比缓冲大小重要。哪怕你设了 make(chan int, 1000)，只要某个 stage 忘了 close(out)，下游 range 就永远等不到 EOF；而过早 close(out)，上游还在写，就会 panic: send on closed channel。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
