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）。
实操建议：
- 只由**发送方**负责关闭 channel，且仅关闭一次 —— 通常放在发送循环结束后
- 用
defer close(ch)容易误关（比如函数提前 return），应改用明确的关闭逻辑 - 中间阶段既要读又要写，不能直接 close(in) 或 close(out)，要用
for range in+ 单独 close(out) - 如果某阶段可能跳过部分输入（如过滤），仍要确保输出 channel 被关闭，否则下游
range永不结束
示例片段：
func multiplyBy2(in <h3>如何安全地传播错误和提前终止整个 Pipeline</h3><p>标准 Pipeline 模式默认不处理错误 —— 一旦某个阶段 panic 或返回 error，上游还在发、下游还在等，整个流水线就卡死或漏数据。Go 没有“中断所有 goroutine”的原语，得靠额外 channel 控制。</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><p>实操建议：</p>
- 引入
donechannel（类型为），所有阶段监听它，收到信号立即退出 - 错误信息通过单独的
errCh chan error传出，由主调方 select 处理 - 不要在中间阶段 recover panic 并吞掉 —— 这会让错误不可见；应该让 panic 传播到顶层，或转为 error 发送到 errCh
- 使用
context.Context是更通用的做法：ctx.Done()替代自定义 done channel，ctx.Err()获取终止原因
典型结构：
func stage(ctx context.Context, in <h3>缓冲 channel 选多大？别盲目设 1024</h3><p>无缓冲 channel（<code>make(chan int)</code>）要求发送和接收必须同步，适合强顺序、低吞吐场景；有缓冲 channel（<code>make(chan int, N)</code>）能解耦生产/消费速率，但缓冲区大小直接影响内存占用和背压行为。</p><p>容易踩的坑：</p>
- 设太大（如 10000）→ 内存暴涨，尤其传大结构体时；goroutine 积压导致 OOM
- 设太小（如 1）→ 频繁阻塞，吞吐上不去，和无缓冲区别不大
- 忽略 GC 压力：channel 缓冲区里存的是值拷贝，如果类型含指针，会延长对象生命周期
建议做法：
- 先用无缓冲测通路逻辑，再根据压测结果调缓冲大小
- 若阶段处理时间波动大（如 IO 不稳定），缓冲设为平均处理耗时 × 预期并发数
- 对内存敏感场景，优先用无缓冲 + 合理的 goroutine 数量控制（如用
semaphore限流）
真正难的不是写对几个 goroutine 和 channel，而是想清楚每个阶段的失败边界、数据完整性保证、以及当 ctx 被 cancel 时，正在传输中的那几个 int 到底算不算成功。这些细节不会报错，但会让线上行为难以预测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
