无缓冲channel适合需强顺序保证或精确协作的场景，如主goroutine等待子任务完成、一次性通知（关闭信号/就绪/中断）、调试瓶颈；误当队列使用会导致死锁。
无缓冲channel适合什么场景？
无缓冲channel（make(chan T)）本质是同步点，发送和接收必须“碰头”才能完成。它不存数据，只做协调——所以适合所有需要强顺序保证或精确协作的场合。
- 主goroutine等待子任务完成：
done := make(chan struct{})，子goroutine执行完立刻发信号，主goroutine一收就继续，不会漏、不会延 - 一次性通知：如关闭信号、初始化就绪、错误中断，用
close(ch)配合range或判断更安全 - 调试瓶颈：把原本带缓冲的
ch临时改成make(chan T, 0)，立刻暴露谁没在消费、谁卡住了
常见错误是把它当队列用——比如往make(chan int)里连发5次，第2次就死锁。这不是bug，是设计误用。
有缓冲channel该设多大？
缓冲大小不是性能参数，而是节奏调节器。它不能解决长期背压，只能争取几十毫秒的调度窗口。盲目设1024或64大概率掩盖问题。
- 突发流量（如API网关入口）：缓冲 ≈ 峰值QPS × 平均处理延迟。例如峰值800 QPS、下游平均耗时40ms →
make(chan *Req, 32) - 日志采集链路：上游缓冲略大于下游吞吐，比如格式化goroutine每秒处理200条，就设
logCh := make(chan string, 250) - 信号类channel（
done、tick）：一律用0缓冲。传控制语义不需要积压
超过1000容量后，GC压力明显上升，且延迟反而增加——runtime要管理更大底层数组，内存碎片也变多。
立即学习“go语言免费学习笔记（深入）”；
性能差异到底在哪？
关键不在“快慢”，而在阻塞行为是否符合预期。无缓冲channel每次通信都触发goroutine切换（send阻塞→唤醒receiver→receiver阻塞→唤醒sender），开销稳定但延迟高；有缓冲channel在缓冲未满/非空时走快速路径，避免调度，吞吐更高。
- 高频小消息（如指标打点）：用无缓冲反而更容易定位卡点；用大缓冲可能让goroutine“假活跃”，实际数据已在channel里睡大觉
- 批量任务分发：设
tasks := make(chan *Task, 100)可减少worker频繁唤醒，但若消费者长期跟不上，len(ch)持续接近cap(ch)就是明确告警信号 - 不要依赖
len(ch)做精确流控——它是非原子读，仅作采样参考；真要背压反馈，得用select+default探测写入是否失败
容易踩的坑有哪些？
最常被忽略的是语义混淆：把“能不阻塞”当成“应该不阻塞”，结果掩盖了消费能力不足的真实问题。
- 用
select { case ch 丢日志很常见，但如果default频发，说明下游已严重滞后，该扩容worker而不是调大buffer - 关闭已关闭的channel会panic；向已关闭的channel发送数据也会panic——务必确保只有发送方有权
close(ch)，且只close一次 - 多个goroutine共用一个大缓冲channel时，容易因争抢底层数组引发伪共享（false sharing），此时拆成多个shard channel（如按hash分片）比硬扩buffer更有效
缓冲区不是银弹，它是系统节奏的刻度尺——读不准，整个流水线就会跑调。
