有缓冲与无缓冲channel选择技巧

Golang中channel的选择关键在于理解其设计本质：无缓冲channel天生要求发送与接收双方严格同步，一发即阻塞正是其强制步调一致的机制体现，而非缺陷；真正决定选用有缓冲还是无缓冲的，不是“是否希望阻塞”，而是业务逻辑是否需要这种严格的协作节奏——忽视这一核心判断，后续的所有配置、调试和压测都可能偏离方向、徒劳无功。

选无缓冲还是有缓冲，不看“要不要阻塞”，而要看你是否需要强制双方步调一致。如果漏掉这个判断依据，后面所有配置、调试、压测都可能白忙。

无缓冲 channel 一发就卡住，是设计使然，不是 bug

执行 ch := make(chan int) 后，ch 立即阻塞，直到有 goroutine 同时执行 。这不是延迟，是 runtime 层面的 rendezvous（会合）机制。

• 常见死锁现象：fatal error: all goroutines are asleep - deadlock!，尤其出现在主 goroutine 先发后收、或只发不收时
• 典型适用场景：启动同步（子 goroutine 初始化完再通知主 goroutine）、done 信号（done := make(chan struct{})）、暂停/恢复控制流
• 它不占额外内存，但对执行顺序极度敏感——别指望它存数据，它根本没地方存

有缓冲 channel 的阻塞点只在满/空两个边界

执行 ch := make(chan int, 3) 后，前 3 次 ch 都立刻返回；第 4 次才阻塞，直到有人执行 腾出空间。

• 缓冲区是固定大小的环形队列，创建后不可扩容；设为 0 等价于无缓冲，负数会 panic
• 容易误判：以为 cap(ch) == 1 就“最多收一次”，其实它允许你连续发 1 次不阻塞，但第 2 次才卡——而接收端哪怕还没动，第一次发送也已完成
• 性能影响：小缓冲（1–16）可平滑突发流量；过大（如 10000）会掩盖背压，让生产者狂写、消费者永远追不上，最终 OOM

关闭 channel 时，缓冲区残留数据必须被显式消费

关闭一个有缓冲的 channel 后， 仍能读出缓冲中剩余数据；读完才返回零值和 false。但这些数据不会自动 GC——底层 hchan 结构仍持有引用。

• 反模式：用 for range ch 消费，但接收逻辑提前 return 或 panic，导致缓冲未清空就退出
• 正确做法：确保接收端逻辑覆盖“通道关闭 + 缓冲未清空”情况；不要依赖超时跳过，也不要忽略剩余值
• 关闭权必须唯一：仅由**最后一个生产者**调用 close(ch)；多个 goroutine 同时写且争抢 close，极易引发 panic: close of closed channel

缓冲大小不是配置项，是并发契约的一部分——它隐式定义了“最多允许多少工作积压”。设成 100 不代表更稳，只是把 OOM 延后了；得结合平均处理耗时、峰值 QPS 和内存预算反推。

理论要掌握，实操不能落！以上关于《有缓冲与无缓冲channel选择技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！