Pipeline 是 Go 中基于 chan 和 goroutine 构建的数据流模型，表现为上游生产→中间多阶段处理→下游消费的串接 channel 链，需由发送方显式关闭 channel 以避免下游阻塞。
什么是 Pipeline 模式在 Go 里的实际表现
Pipeline 不是 Go 内置语法，而是基于 chan 和 goroutine 构建的数据流模型：上游生产数据 → 中间多阶段处理 → 下游消费结果。它本质是一串串接的、带缓冲或无缓冲的 channel，每个阶段启动独立 goroutine，靠 channel 阻塞/非阻塞特性协调并发节奏。
关键判断：如果你需要把一个耗时操作拆成“读取→解析→转换→写入”等可并行又需顺序依赖的环节，Pipeline 就比单纯开一堆 goroutine 更可控；但若只是并行跑 N 个互不依赖的任务，用 sync.WaitGroup 或 errgroup.Group 更轻量。
必须显式关闭 channel 否则下游 goroutine 永远卡住
Go 的 channel 关闭是单向信号，range 语句依赖它退出，但关闭时机极易出错。常见错误是上游 goroutine panic 未关闭 channel，或多个 goroutine 试图重复关闭同一 channel（触发 panic: send on closed channel）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只由**发送方**负责关闭 channel，且仅关闭一次 —— 通常放在发送循环结束后
- 用
defer close(ch)容易误关（比如函数提前 return），应改用明确的关闭逻辑 - 中间阶段既要读又要写，不能直接 close(in) 或 close(out)，要用
for range in+ 单独 close(out) - 如果某阶段可能跳过部分输入（如过滤），仍要确保输出 channel 被关闭，否则下游
range永不结束
示例片段：
func multiplyBy2(in <-chan int) <-chan int {
out := make(chan int)
go func() {
defer close(out) // 正确：在 goroutine 内部 close 输出 channel
for v := range in {
out <- v * 2
}
}()
return out
}如何安全地传播错误和提前终止整个 Pipeline
标准 Pipeline 模式默认不处理错误 —— 一旦某个阶段 panic 或返回 error，上游还在发、下游还在等，整个流水线就卡死或漏数据。Go 没有“中断所有 goroutine”的原语，得靠额外 channel 控制。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 引入
donechannel（类型为<-chan struct{}），所有阶段监听它，收到信号立即退出 - 错误信息通过单独的
errCh chan error传出，由主调方 select 处理 - 不要在中间阶段 recover panic 并吞掉 —— 这会让错误不可见；应该让 panic 传播到顶层，或转为 error 发送到 errCh
- 使用
context.Context是更通用的做法：ctx.Done()替代自定义 done channel，ctx.Err()获取终止原因
典型结构：
func stage(ctx context.Context, in <-chan int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for {
select {
case v, ok := <-in:
if !ok {
return
}
select {
case out <- v * 2:
case <-ctx.Done():
return
}
case <-ctx.Done():
return
}
}
}()
return out
}缓冲 channel 选多大？别盲目设 1024
无缓冲 channel（make(chan int)）要求发送和接收必须同步，适合强顺序、低吞吐场景；有缓冲 channel（make(chan int, N)）能解耦生产/消费速率，但缓冲区大小直接影响内存占用和背压行为。
容易踩的坑：
- 设太大（如 10000）→ 内存暴涨，尤其传大结构体时；goroutine 积压导致 OOM
- 设太小（如 1）→ 频繁阻塞，吞吐上不去，和无缓冲区别不大
- 忽略 GC 压力：channel 缓冲区里存的是值拷贝，如果类型含指针，会延长对象生命周期
建议做法：
- 先用无缓冲测通路逻辑，再根据压测结果调缓冲大小
- 若阶段处理时间波动大（如 IO 不稳定），缓冲设为平均处理耗时 × 预期并发数
- 对内存敏感场景，优先用无缓冲 + 合理的 goroutine 数量控制（如用
semaphore限流）
真正难的不是写对几个 goroutine 和 channel，而是想清楚每个阶段的失败边界、数据完整性保证、以及当 ctx 被 cancel 时，正在传输中的那几个 int 到底算不算成功。这些细节不会报错，但会让线上行为难以预测。
