无缓冲 channel 并非真正同步，而是协程间握手式阻塞：发送方必须等待接收方就绪才能继续，本质是同步阻塞而非高效同步。
缓冲区大小为 0 就一定同步？别被直觉骗了
无缓冲 chan int 确实强制发送与接收 goroutine 同时就绪，但“同步”不等于“高效”。它本质是协程间的一次握手：发送方卡在 ch ，直到接收方执行到 才继续。这在控制信号（如 done 通知）、状态切换等场景很干净；但一旦生产者或消费者稍有延迟，整条流水线就卡住。
- 典型误用：用无缓冲 channel 传日志事件——生产者每毫秒发一条，消费者处理需 5ms，第 2 条就会阻塞，导致上游 goroutine 积压甚至 OOM
- 正确思路：先问“这里需要的是协调时机，还是解耦速度？”——要时机选
make(chan struct{})；要吞吐，就得给缓冲 - 调试技巧：用
go tool pprof -goroutines查看阻塞在chan send或chan recv的 goroutine 数量，飙升就是同步瓶颈信号
怎么算出该设多大？套公式不如看压测拐点
网上流传的 bufferSize = (生产速率 − 消费速率) × 最大容忍延迟 是理论下限，实际必须叠加内存和背压策略。比如日志系统中，你算出要 800，但若单条日志 1KB，缓冲区就占 800KB 内存——而你的边缘设备只有 2MB 可用堆，这就不可行。
- 推荐做法：从
make(chan *LogEntry, 16)起步，用ab或hey模拟 2× 峰值流量，观察runtime.ReadMemStats().HeapAlloc和 channel 阻塞率（通过debug.ReadGCStats间接估算） - 关键拐点：当缓冲区从 64 → 128 时，P99 延迟下降 5ms，但从 128 → 256 几乎无变化，且内存增长 30%，此时 128 就是性价比拐点
- 硬限制：永远不要让缓冲区元素总内存超过应用堆的 5% —— Go GC 对大对象链敏感，过大的 channel 缓冲会拖慢 STW
缓冲区设太大反而更慢？真实性能陷阱在这里
缓冲区不是越大越好。实测发现：当 make(chan int, 10000) 时，goroutine 在写满后首次阻塞的耗时，比 make(chan int, 100) 高出 3–5 倍——因为 runtime 要遍历整个环形缓冲区判断是否 full，而底层 hchan 的 sendq 队列查找开销随长度非线性增长。
- 常见症状：高并发下 CPU 使用率不高，但 channel 写入延迟毛刺明显（>10ms），
pprof trace显示大量时间花在chan.send的锁竞争上 - 规避方法：对高频小数据（如指标计数器），优先用
sync/atomic；对中低频大数据（如图片帧），缓冲区上限建议 ≤ 1024，再大就拆成多个 channel + 负载均衡 goroutine - 特别注意：
range遍历带缓冲 channel 时，如果生产者未 close，消费者会永远等不到 EOF——这和无缓冲 channel 行为一致，但容易被忽略
生产环境必须加的三道保险
线上服务里，光选对缓冲区不够，得防住缓冲区满、goroutine 泄漏、channel 关闭混乱这三类高频事故。
立即学习“go语言免费学习笔记（深入）”；
- 缓冲区满时拒绝而非阻塞：
select { case ch <- item: default: metrics.Counter("channel_dropped").Inc() // 或 return errors.New("channel full") } - 避免 goroutine 泄漏：所有写 channel 的 goroutine 必须有退出路径，推荐用
context.WithTimeout包裹，超时后close(ch)并 return - 关闭前确认无人写入：永远只由生产者 close，且 close 前确保所有发送 goroutine 已退出；消费者用
value, ok := 判断是否 closed，别依赖for range自动退出（万一生产者忘了 close 就死锁）
缓冲区选择本质是吞吐、延迟、内存、稳定性四者的权衡点，没有银弹。最危险的不是选错数字，而是选完就不管——定期用 go tool pprof -http=:8080 看 channel 阻塞热图，比任何理论都管用。
