Go中的管道-过滤器是基于函数组合的同步数据处理链，本质为纯函数调用链（如f3(f2(f1(data)))），而非依赖channel的并发模型；它强调类型一致的Filter函数（func([]byte) []byte）显式串联，不涉及goroutine、缓冲区或阻塞调度。
什么是 Go 里的管道-过滤器，它和 channel 有什么区别？
管道-过滤器不是靠 chan 自动串联的“流式系统”，而是用函数组合显式构建数据处理链。每个过滤器是接收一个输入、返回一个输出的纯函数（比如 func([]byte) []byte），管道则是把这些函数按顺序串起来：前一个的输出直接喂给后一个。它不依赖 goroutine 或缓冲区，也没有阻塞/调度开销——本质是函数调用链，不是并发模型。
常见误解是把 go func() { ... }() + chan 当成管道-过滤器，那其实是生产者-消费者模式；真正的 Pipeline-Filter 关键在「类型一致的函数组合」，不是「数据在 channel 里跑」。
怎么用函数值拼出可复用的管道？
核心是定义统一的过滤器类型，比如：
type Filter func([]byte) []byte然后用可变参数函数把多个
Filter 串成一个：func Pipeline(filters ...Filter) Filter {
return func(data []byte) []byte {
for _, f := range filters {
data = f(data)
}
return data
}
}
- 每个
Filter必须接受和返回相同类型（如[]byte），否则无法链式调用 - 顺序很重要：
Pipeline(f1, f2, f3)等价于f3(f2(f1(data)))，不是反向 - 如果某个过滤器可能失败（比如解码错误），不要返回
error—— 那会破坏类型一致性；改用 panic 或提前终止（如返回 nil 并由下游检查）
如何让过滤器支持上下文或状态？
纯函数没法带配置，所以实际中常需要闭包封装参数。例如带 base64 编码选项的过滤器：
func Base64Encoder(enc *base64.Encoding) Filter {
return func(data []byte) []byte {
dst := make([]byte, enc.EncodedLen(len(data)))
enc.Encode(dst, data)
return dst
}
}
- 不要把
*http.Request或context.Context塞进Filter类型签名——那会让管道失去通用性 - 状态应通过闭包捕获，而不是作为参数传入每次调用；否则就退化成普通函数调用，失去组合能力
- 如果真需要上下文传递（比如超时控制），得改用
func(context.Context, []byte) ([]byte, error)类型，但此时已不属于经典 Pipeline-Filter 模型
什么时候不该用这种函数式管道？
当数据量大、单步耗时长、或需要背压控制时，硬拼函数调用链会卡住整个流程。比如一个过滤器要花 500ms 处理 1MB 数据，那 Pipeline(f1, f2, f3) 就是同步阻塞执行，无法并行或限速。
- IO 密集操作（如 HTTP 请求、磁盘读写）不适合放在这里——它们该走 goroutine + channel
- 内存敏感场景要注意：每个过滤器都可能分配新 slice，
f3(f2(f1(data)))可能产生 3 次拷贝，而原地修改的 filter 更省，但会牺牲纯度 - 调试困难：函数链里某一步 panic，堆栈只显示
Pipeline.func1，没具体过滤器名——建议在每个 filter 里加简短日志或包装器
真正关键的是别混淆「组合逻辑」和「并发调度」：Pipeline-Filter 解决的是「怎么组织转换步骤」，不是「怎么跑得更快」。
