go管道模式卡死、数据丢失、goroutine泄漏主因是chan缓冲、关闭与消费逻辑不匹配；for range panic因stage退出时机错位，上游未停写下游已关channel；无缓冲chan易阻塞，应按io或cpu密集型合理设置缓冲大小。
Go 的管道模式不是“写完就能跑”，清洗流程卡死、数据丢失、goroutine 泄漏，八成出在 chan 的缓冲、关闭和消费逻辑上。
为什么用 for range ch 会 panic “send on closed channel”
这不是 channel 本身的问题，而是 stage 之间退出时机没对齐。上游还在往 out 发数据，下游 stage 已经 close(out) 并退出，但上游 goroutine 还没收到“该停了”的信号。
- 典型错误：在 stage 函数里用
defer close(out)，但函数因context.Cancelled提前返回，defer仍执行，此时上游可能正尝试发送 - 正确做法：所有退出路径（正常结束、
ctx.Done()、recover()后）都先停止写入，再统一close(out) - 不要在
for range in循环体内直接close(out)——最后一批数据还没发完就关了 - 若 stage 是 filter（跳过部分输入），不能依赖
range in结束来触发close(out)，得靠计数或标志位确认“真处理完了”
无缓冲 chan 在清洗 pipeline 中为何大概率导致阻塞
无缓冲通道要求发送和接收必须同时就绪，而清洗各阶段耗时天然不均——HTTP 请求慢、正则解析快、JSON 序列化又慢。硬用 make(chan T) 等于把整条流水线锁死在最慢环节。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- IO 密集型 stage（如调第三方 API 校验手机号）：用
make(chan T, 100)，防瞬时积压拖垮上游 - CPU 密集型 stage（如批量 JSON 解析）：缓冲设为
runtime.NumCPU() * 2～*4，避免线程切换开销过大 - 绝对不要用
make(chan T, 0)串联多个 CPU 密集 stage——这等于强制串行化，协程优势全丢 - 缓冲太大（如 10000）也不行：脏数据全缓住，错误延迟暴露，掩盖真实的数据质量问题
如何安全地向下游 channel 发送数据而不卡死
永远别裸写 out 。上游不能被下游临时不可用拖垮，尤其当清洗链路长、某 stage 偶发卡顿或 panic 时。
- 必须用
select+default实现非阻塞发送：select { case out - 若需超时控制（如防止某个 stage 卡太久），改用带超时的封装：
sendWithTimeout(out, x, 5*time.Second) - 多个 stage 想同时消费同一份原始数据？别开两个
for range ch——Go channel 是单消费者语义，第二个循环永远收不到。必须显式 fan-out：起一个分发 goroutine，把每个值复制到多个输出chan - 旁路日志（如审计、调试）要单独开只读副本，别和主清洗流共用 channel
pipeline 终止时 goroutine 泄漏的真实原因
泄漏不是因为代码写得“不够优雅”，而是三类底层 channel 行为没兜住：向已关的 out 持续发、从无发送者的 in 无限收、超时控制缺失导致 select 卡死。
- 每个 stage 启动时必须传入
ctx context.Context，并在主循环中select监听ctx.Done() - IO 密集型清洗（如 DB 写入）若超时卡住，它持有的
in就一直没人消费，整个 goroutine 挂起不退 - 别用
close()当同步信号——某 stage 提前退出误关共享输入 channel，其他 stage 会提前结束；该用sync.WaitGroup或context.Context控制生命周期 - 真实爬虫场景跑一小时后 OOM，查下来常是几百个 goroutine 卡在
ch上：下游 stage 已 panic 退出，但没通知上游停手；Go 管道没有内置反压或取消传播
缓冲大小、关闭时机、发送方式——这三个点任意一个没对齐，pipeline 就不是加速器，而是定时炸弹。实际压测时，盯着 len(ch) 波动比看文档更管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
