无缓冲通道易导致协程阻塞停摆，清洗环节应设合理缓冲（如50~200），并用select+default实现非阻塞发送。
Go 中 chan 不加缓冲就容易卡死
管道模式在爬虫清洗流程里不是“用了就爽”，而是“不设缓冲就停摆”。chan int 这种无缓冲通道，要求发送和接收必须同时就绪，否则协程直接阻塞——爬虫里一个解析 goroutine 卡住，整个流水线就挂了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 清洗阶段每个环节（如去重、字段标准化、过滤）都用
make(chan T, 100)设合理缓冲，数值按单批次数据量预估，别写死1或1024 - 若上游是 HTTP 抓取（可能慢），下游是 CPU 密集型清洗（可能忙），缓冲太小会导致抓取协程频繁等待，太大又浪费内存；推荐从
50~200起调，压测时观察len(ch)波动 - 永远用
select+default做非阻塞发送，避免因下游暂时无法接收而拖垮上游：select { case out <- item: default: // 记录丢弃或降级处理 }
多个 range 读取同一 chan 会漏数据
常见错误：想让“去重”和“格式校验”两个 stage 同时消费原始数据流，就开了两个 for range ch ——结果只有一个能收到值，另一个永远等下去。Go 的 channel 是“单消费者”语义，不是广播。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 需要多路分发，必须显式用 fan-out 模式：起一个分发 goroutine，把输入
chan的每个值复制到多个输出chan - 别用
close()当同步信号。清洗流程中某个 stage 提前退出，如果误关了共享输入 channel，其他 stage 会提前结束；应改用sync.WaitGroup或context.Context控制生命周期 - 如果某 stage 需要“旁路日志”但不参与主流程，单独开一个只读副本：
go func() { for item := range in { log.Printf("raw: %+v", item) } }()
pipeline 终止时资源泄漏比想象中严重
爬虫跑一小时后 OOM，查下来不是数据大，而是几百个 goroutine 卡在 ch 上，因为下游 stage 已 panic 退出但没通知上游停手。Go 管道没有内置反压或取消传播。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有 stage 启动时都接收一个
ctx context.Context，并在select中监听ctx.Done()；一旦收到取消信号，立刻停止读/写 channel 并 return - 不要依赖
defer close(ch)。channel 关闭后仍可读，但若下游还在range，会读完缓存后自动退出；真正要关的是 goroutine 本身，不是 channel - 用
runtime.NumGoroutine()在 debug 模式下定期打点，上线前确认峰值 goroutine 数稳定收敛，而不是随任务数线性增长
JSON 解析失败导致整条 pipeline 崩溃
爬虫数据脏，某个 json.Unmarshal 失败，stage 直接 panic，recover 又没包住，整个管道崩掉——这不是异常处理没做，是没想清楚“错误该在哪一层吃”。管道里一个环节出错，不该让上游停摆，更不该让下游收不到后续数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 清洗 stage 内部必须用
if err != nil显式判断 JSON 错误，把坏数据转成带Err字段的结构体，继续往下传，由最后的落库 stage 统一归档到 error topic - 避免在
for range ch循环里直接调json.Unmarshal；先用json.RawMessage做零拷贝预检，再按需解析关键字段，减少 panic 触发面 - 对不可信输入，用
json.Decoder替代json.Unmarshal，配合Decoder.UseNumber()防数字溢出，这是很多线上事故的隐藏原因
实际跑起来最麻烦的从来不是怎么连通几个 chan，而是当第 7 个 stage 开始悄悄积压、第 3 个 stage 的 len(ch) 持续高于阈值、而日志里只有一行 “context canceled” 时，你得快速判断是上游超时、下游卡死，还是某个 time.After 忘了 select 掉。
