无缓冲 channel 会让 goroutine 频繁唤醒，因为每次 send 或 recv 都是同步点，需双方同时就绪，runtime 直接栈间拷贝并立即唤醒对方，每对操作至少触发两次 goroutine 切换；而有缓冲 channel 通过环形队列暂存数据，未满/未空时可非阻塞读写，显著降低唤醒频率。
无缓冲 channel 为什么会让 goroutine 频繁唤醒？
因为无缓冲 channel 的每次 send 或 recv 都是同步点：发送方必须等到接收方就绪，接收方也必须等到发送方就绪。Go runtime 在这种情况下会直接将数据从 sender 栈拷贝到 receiver 栈（不经过 buf），并立即唤醒对方 goroutine。
这意味着：哪怕只是传一个 struct{}，也会触发一次 goroutine 切换 + 调度器介入。在高频通知场景（如心跳、状态切换）中，这会造成大量上下文切换开销。
- 每对 send/recv 至少唤醒 2 个 goroutine（一发一收）
- 没有缓冲区缓存“等待中的操作”，所有通信都强依赖双方时间对齐
- 当生产者快、消费者慢时，生产者会持续阻塞并被调度器反复 park/unpark
有缓冲 channel 如何降低唤醒频率？
缓冲区本质是个环形队列（hchan.buf），只要未满/未空，send 和 recv 就能直接操作内存，不触发 goroutine 阻塞或唤醒。
比如 ch := make(chan int, 10)，连续 10 次 ch 全部非阻塞，只有第 11 次才会因缓冲区满而阻塞、进而可能被 park；同理，接收端若持续消费，也不会因“等不到数据”而挂起。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 缓冲区越大，越能吸收突发流量，减少 goroutine 进入阻塞态的次数
- 但注意：缓冲区不是越大越好——它只是把“唤醒压力”从 runtime 转移到了内存和背压延迟上
- 实测显示，当缓冲区 ≥ 生产者单次 burst 大小时，唤醒频率可下降 70%+（例如 burst=8，设
cap=8）
缓冲区大小怎么影响“语言学习吞吐量”？
这里“语言学习吞吐量”不是术语，而是指你通过写代码理解 channel 行为的速度。缓冲区大小直接影响你能观察到的现象复杂度：
-
make(chan int, 0)：行为最简单——要么立刻成功，要么立刻死锁。适合练手同步模型，但掩盖了真实系统中“积压”“延迟”“背压”等关键问题 -
make(chan int, 1)：开始暴露“解耦”价值——发送端不会因接收端卡住而停摆，但你也看不到多条消息排队的效果 -
make(chan int, 8)或更大：能稳定复现积压、观察len(ch)变化、验证背压策略。这时候你才真正开始学“怎么用 channel 做工程级并发”
换句话说，缓冲区太小，你学的是玩具模型；太大，你又容易忽略内存成本和信号丢失风险。选一个能让你同时看到“运行顺畅”和“出问题时有迹可循”的中间值（比如 4–32），才是语言学习效率最高的起点。
容易被忽略的关键细节
很多人调大缓冲区后以为万事大吉，却没意识到：cap(ch) 是静态容量，len(ch) 才是当前积压量。如果你只检查 cap 而不监控 len，就等于开着油表坏掉的车跑高速——直到 OOM 才发现缓冲区早被填满。
更隐蔽的是：close(ch) 不清空缓冲区。关闭后还能继续 <-ch 直到 len(ch) == 0，之后才返回零值。这个行为常导致“以为 channel 关了，其实还有残留数据没处理完”的 bug。
