go channel默认无缓冲导致发送阻塞，需用goroutine、缓冲区、for-range/select消费及正确close；错误传递需errchan+done通道；并发map须用sync.rwmutex/atomic；扩缩容需动态worker调度。
为什么 chan 做流水线阶段间通信时容易卡死
因为 Go 的 channel 默认是无缓冲的，上游往 chan 发送数据会阻塞，直到下游从同一 chan 接收——如果某个阶段没及时消费，整条流水线就停在那儿了。
常见错误现象：fatal error: all goroutines are asleep - deadlock，尤其在最后阶段没启动 goroutine 消费、或中间某阶段 panic 退出却没关闭 channel 时高频出现。
- 每个阶段必须用
go func() { ... }()启动独立 goroutine，不能同步调用 - 所有
chan建议显式指定缓冲区大小，比如make(chan int, 100)，避免一发就卡 - 下游必须用
for range或带ok判断的select消费，否则上游 close 后仍会阻塞 - 阶段函数内部不要直接 close 输入 channel，只 close 自己输出的 channel
pipeline 中怎么安全地传递错误和提前终止
标准的 for-range + channel 流水线不带错误传播能力。一旦某阶段出错（比如解析失败、IO 超时），默认行为是继续跑完所有输入，浪费资源还掩盖问题。
使用场景：ETL 处理一批日志，其中一条格式异常，你希望立刻停止并返回错误，而不是等几万条都处理完才报错。
立即学习“go语言免费学习笔记（深入）”；
- 加一个额外的
errChan chan error，所有阶段遇到错误都往里发一次，但只发一次（避免重复发送） - 主流程用
select等待正常数据或错误，收到错误后调用close()所有下游 channel 并 return - 各阶段需监听自己的
donechannel（类型），用于响应中断，避免 goroutine 泄漏 - 别用
panic替代错误传递——它无法被上层 recover，还会导致 goroutine 意外退出
多个 goroutine 读写同一个 map 导致 fatal error: concurrent map read and map write
流水线中常需要共享状态，比如统计每个 stage 的处理耗时、累计成功/失败数。直接用全局 map[string]int 并发读写必崩。
性能影响：用 sync.RWMutex 包裹 map 是最常用解法，但高并发写多场景下锁竞争明显；sync.Map 适合读多写少，但不支持遍历和 len()，且接口略别扭。
- 优先考虑把状态拆到每个 stage 内部，用局部变量+返回值聚合，避免共享
- 真要共享计数器，用
sync/atomic的Int64或Uint64，比锁快得多 - 如果必须用 map 且读写均衡，用
sync.RWMutex，读操作用RLock()/RUnlock()，写用Lock()/Unlock() - 别在 defer 里 unlock —— 如果 lock 失败，defer 会 panic；先判空再 lock
如何让 pipeline 支持动态扩缩容（比如根据 CPU 负载增减 worker 数量）
硬编码 for i := 0; i 看似简单，但实际部署时负载波动大，固定 worker 数要么压不住流量，要么空转吃资源。
兼容性注意：Go 1.21+ 的 context.WithCancelCause 可以更清晰地传递取消原因，但老版本只能靠额外 error channel 配合 done channel 模拟。
- worker 数量做成可配置参数，启动时传入，而非写死
- 每个 worker 在循环内检查
ctx.Done()，并在退出前通知上游“我已退出”（比如发信号到workerDone chan struct{}） - 扩容逻辑放在独立 goroutine 里，定期采样
runtime.NumGoroutine()或自定义指标，触发时起新 worker - 缩容不能暴力 kill goroutine，只能发 cancel，等当前任务做完再退出；否则可能丢数据或破坏原子性
流水线真正难的不是搭起来，而是每个阶段的边界是否清晰、错误是否可追溯、资源是否可回收——这些地方不细想，上线后只会更难 debug。
