无缓冲 channel 在 hot path 上性能差，因其每次发送/接收需 goroutine 切换与同步等待，导致高延迟和调度开销。
Go 中 channel 本身不慢，慢的是误用——goroutine 泄漏、高频创建、无缓冲卡死、大结构体拷贝、盲目关闭，这些才是真实瓶颈。
为什么无缓冲 channel 在 hot path 上会拖垮性能
无缓冲 make(chan int) 每次 或 都强制双方 goroutine 同时就绪，触发调度器介入、上下文切换和锁竞争。压测中常看到 runtime.chansend 占 CPU 30%+，其实不是 channel 慢，是它在反复“叫醒-挂起”协程。
- 高频日志打点、网络包解析、指标上报等循环场景，绝不要在 for 里
ch := make(chan int) - 正确做法：把 channel 作为结构体字段或包级变量初始化一次，生命周期与业务对齐
- 若必须同步信号（如等待初始化完成），用
done := make(chan struct{})是轻量的，但仅限低频协调，不用来传数据
缓冲区大小怎么设才不踩坑
缓冲不是越大越好，make(chan *LogEntry, 1e6) 看似“保险”，实则危险：一旦消费者卡住，发送方持续分配底层数组，GC 频繁 STW，内存飙升，延迟不可控。
- 按「峰值吞吐 × 处理延迟」估算：比如每秒最多 200 条日志，平均处理耗时 100ms → 缓冲 ≈ 200 × 0.1 = 20，再乘 1.5 倍留抖动 →
make(chan *LogEntry, 32) - HTTP 请求队列常见
make(chan *http.Request, 1024)，对应千级 QPS + 百毫秒延迟 - 避免
make(chan int, 1)这类“伪缓冲”：容量为 1 几乎等效于无缓冲，还多占内存
如何避免 channel 引发 goroutine 泄漏
泄漏最常见于“生产者还在发，消费者已退出但没关 channel”，或者“接收方用 for range ch 却没处理完残留数据就退出”。pprof 里看到大量 goroutine 停在 chanrecv，基本就是这个原因。
立即学习“go语言免费学习笔记（深入）”；
- 发送方关闭前，必须确认所有数据已发出且不会再发；推荐用
sync.WaitGroup收尾后close(ch) - 接收端永远用双返回值：
if val, ok := ，单用会永久阻塞 - 更安全的替代：用
context.Context控制生命周期，worker 监听ctx.Done()而非等 channel 关闭 - 非关键路径写入（如监控上报）优先用
select { case ch ，失败即丢弃并打 metric
什么时候该放弃 channel
当出现以下信号，说明 channel 已从协作工具退化为性能枷锁：
-
pprof显示大量时间花在runtime.chansend/runtime.chanrecv - 需要精确背压（如硬限流到 500 QPS），而
select+time.After不够稳定 - 单生产者单消费者且数据结构固定，
sync.Pool+sync.Mutex+ slice 实现的环形队列反而更低开销 - 高吞吐流水线中某 stage 成为瓶颈，却因 channel 阻塞拖垮全局——这时应拆 stage、加 worker 数，而不是调大 buffer
channel 的价值在于清晰表达“谁等谁、等什么、等多久”，而不是堆参数硬扛流量。真正难的从来不是语法，是判断哪条 goroutine 该等、该等几毫秒、等不到时该降级还是 panic。
