流水线数据卡在中间不动的根本原因是某个stage的goroutine未正确关闭输出channel或消费者提前退出，导致上游send操作永久阻塞，因go channel默认同步。
流水线处理本身不提升吞吐量，真正起作用的是控制阻塞、复用资源和匹配生产/消费节奏；盲目加 stage 或 goroutine 反而会让数据卡在 channel 里，CPU 利用率上不去。
为什么 pipeline 数据会卡在中间不动
根本原因不是 channel 没数据，而是某个 stage 的 goroutine 没正确关闭输出 channel，或者消费者提前退出，导致上游 send 操作永久阻塞——Go 的 channel 默认同步，out 会一直等下游 <code>range in 或 准备好。
- 每个 stage 必须用
for x := range in读输入，而不是select { case x, ok := ，否则容易漏掉 close 信号 - stage 内部不能另起 goroutine 往
out写，否则close(out)时机不可控 - 务必在处理完所有输入后显式
close(out)，不能依赖 defer（defer 在 goroutine 退出时才执行，但上游可能已卡住）
如何让 pipeline 支持错误传递和及时终止
原生 channel 没有错误语义，close() 只表示“流结束”，无法区分成功完成还是出错中断。靠 panic 跨 goroutine 传播也不现实。
- 推荐统一用结构体封装结果：
type Result struct { Value T; Err error }，所有 stage 共用一个chan Result - 任意 stage 遇到错误，立即
close(out)并发送Result{Err: xxx}，下游收到后应停止从该 channel 读取 - 必须配合
context.Context：每个 stage 启动时传入 ctx，在select中监听ctx.Done()，避免 goroutine 泄露
worker pool + pipeline 怎么配才不拖慢吞吐
纯 channel 流水线适合逻辑清晰、各 stage 耗时均衡的场景；一旦某 stage 明显变慢（比如调外部 API），整个 pipeline 就被拖住。这时要把重负载 stage 替换为 worker pool。
- 把慢 stage（如 HTTP 请求、DB 查询）改成固定数量的 goroutine 从带缓冲 channel 消费任务，例如：
jobs := make(chan Task, 1000) - worker 数量设为
runtime.GOMAXPROCS(0) * 2左右，别盲目堆到 100+；若该 stage 主要是 I/O，可适当放大，但必须配http.Client.Timeout和连接池 - 上游 stage 向
jobs发送时，要用select+default防止因缓冲满而阻塞，或改用带超时的发送：select { case jobs
batch flush 和 channel 缓冲怎么设才不丢数据也不卡死
缓冲大小和 batch 策略直接决定背压是否可控、内存是否暴涨、延迟是否超标。没有通用值，只看你的生产/消费速率差。
- 纯解耦场景（如日志采集）：channel 缓冲设
1024，batch 用time.Ticker定时 flush，比如每 500ms 或满 100 条触发一次 - 强实时场景（如风控决策）：channel 用无缓冲
make(chan T)，靠消费者主动拉取实现天然限流；batch 改成单条处理，避免延迟累积 - 千万别混用：
len(ch)是当前积压数，cap(ch)才是缓冲上限；监控时要看len(ch)/cap(ch)比值，持续 >0.8 就得扩容或降速
最易被忽略的一点：pipeline 的第一个 stage 如果是文件读或网络流，必须用 bufio.Reader 分块读 + io.Copy，而不是一次性 os.ReadFile —— 否则整个流水线在启动瞬间就因内存暴涨卡死，连调度器都来不及介入。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
