缓冲大小设为0不必然同步阻塞；无缓冲channel虽需收发双方同时就绪，但在select+default中可非阻塞操作，性能关键在缓冲容量与吞吐匹配度、内存开销（如大类型值拷贝）及可观测指标。
缓冲大小设为 0 就一定同步阻塞？
不是。无缓冲 channel（make(chan int)）确实要求收发双方 goroutine 同时就绪，但“阻塞”是否发生，取决于调用上下文和调度时机。比如在 select 中配合 default 分支，send 或 recv 操作可以立即失败而非挂起；又或者接收方刚启动但尚未执行 ，此时发送就会阻塞——这和“同步”本质有关，和缓冲区大小数值无关。
常见错误现象：协程卡死、CPU 占用低但任务积压、pprof 显示大量 goroutine 停在 chan send 或 chan recv。这类问题往往不是缓冲区设错了，而是逻辑上没保证至少一个接收者始终活跃。
- 无缓冲 channel 更适合强同步信号场景，如初始化完成通知、goroutine 协作握手
- 若生产者速度波动大，哪怕只设
1的缓冲（make(chan int, 1)），也能避免瞬间背压导致的阻塞 - 不要为了“看起来同步”而硬用无缓冲 channel，尤其在非关键路径上
缓冲大小设为 100 就比 10 快？
不一定。吞吐量提升有明显边际效应：从 0 到 10 可能减少 80% 的阻塞等待，但从 10 到 100 往往只再降 5%~10%，却多占 9 倍内存。更关键的是，缓冲区掩盖了消费侧瓶颈——如果消费者处理慢是因 I/O 或锁竞争，加大缓冲只会让问题延迟暴露，甚至引发 OOM。
使用场景判断比数字更重要：突发流量（如秒杀请求入队）适合固定中等缓冲（10–100），而流式处理（如日志采集 pipeline）更适合结合 context.WithTimeout + select 控制单次写入等待，而非堆大缓冲。
- 基准测试时，用
go test -bench对比不同cap下的BenchmarkChanSend，注意观察 GC pause 和 goroutine count - 线上服务建议从
16或32起步，根据监控中的chan send blocked/sec指标逐步调优 - 避免用
make(chan T, math.MaxInt32)这类“无限缓冲”——它不会真无限，但会迅速耗尽内存并触发 GC 频繁停顿
channel 缓冲大小影响 goroutine 调度行为？
影响显著。无缓冲 channel 的每次收发都会触发一次 goroutine 切换：发送方让出 CPU，调度器唤醒接收方；而有缓冲 channel 在缓冲未满/非空时，发送/接收可直接操作底层 ring buffer，不触发切换。这意味着高频率小数据通信中，缓冲 channel 能降低调度开销。
但反过来说，如果缓冲太小（比如 1），而生产者消费者节奏错配，会导致频繁“写满→阻塞→唤醒→消费→再写满”，实际调度开销可能比无缓冲还高——因为多了 buffer 状态检查和原子计数更新。
- Go runtime 对缓冲 channel 的底层实现是环形数组 + 两个 uint64 计数器（
sendx/recvx），所有操作都需原子指令，缓冲越小，争用概率越高 - 在 fan-out 场景（一个生产者对多个消费者），用带缓冲 channel +
range接收，比无缓冲 + 手动 select 轮询更省调度资源 - 不要假设“缓冲了就一定不调度”，重点看你的 goroutine 是 CPU-bound 还是 I/O-bound；后者通常更受益于缓冲解耦
为什么线上服务常把缓冲大小设成 2 的幂次？
不是性能必须，而是工程惯性。Go runtime 内部对 channel 的缓冲区分配没有特殊优化 2 的幂次，但很多团队沿用 16、64、256 这类值，是因为它们便于估算内存占用（cap * unsafe.Sizeof(T)），也方便监控告警阈值对齐（比如“缓冲使用率 > 90%”对应整除计算）。真正影响性能的是绝对容量与业务吞吐的匹配度，不是数字本身是不是 2 的幂。
容易被忽略的一点：当 T 是指针或大结构体时，缓冲区存的是值拷贝。如果 T 占 1KB，缓冲设为 1024，光 channel 自身就占约 1MB 内存——这个成本远高于调度开销，必须进 GC 压力评估。
- 用
unsafe.Sizeof和runtime.ReadMemStats定期验证 channel 内存占比 - 若
T较大，优先考虑传指针（chan *T）并确保生命周期可控，而不是盲目加大缓冲 - 缓冲大小最终要落在可观测指标上：P99 发送延迟、缓冲区平均填充率、goroutine block time —— 而不是代码里写个“看着顺眼”的数字
