无缓冲channel要求发送和接收必须同步配对，多生产者写入时若无消费者即时接收，首个写操作即阻塞；同理多消费者读取时若无生产者写入，首个读操作也阻塞，导致程序启动即卡死。
为什么 chan int 直接用会卡死
多生产者往无缓冲 channel 写、多消费者从里面读，最常见现象是程序启动后立刻阻塞——某个 producer 在 ch 处挂住，因为没消费者在等。这不是 bug，是 Go channel 的同步语义决定的：无缓冲 channel 要求发送和接收**同时就绪**才能通行。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 除非你明确需要“握手式”强同步（比如初始化协调），否则多生产者场景下别用无缓冲 channel
- 缓冲区大小不是越大越好：
make(chan int, 1000)看似安全，但若消费者长期慢于生产者，内存持续增长，最终 OOM - 缓冲区设为 1 是个实用折中：它不保证不丢数据，但能平滑突发写入，又避免过度积压
select 配 default 不等于“非阻塞写”
很多人用 select + default 想实现“尽力写”，结果发现消费者一停，生产者迅速把缓冲区填满，之后所有写都走 default 分支，数据直接被丢弃——这往往不是预期行为。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认业务能否容忍丢数据；如果不能，
default分支该做的事是日志告警或降级（比如写本地磁盘暂存），而不是静默跳过 - 想真正控制背压，得配合
context.WithTimeout或time.After做超时写入：case ch 成功，<code>case 超时则处理异常 - 注意：在循环里反复
select+default会吃高 CPU，尤其 channel 长期满载时
用 sync.WaitGroup 控制生产者退出时机很关键
生产者 goroutine 通常跑在 for-range 或 for-select 循环里，但消费者可能提前结束，而生产者不知道该不该停。如果生产者一直发、消费者已退出，channel 缓冲区迟早溢出或 goroutine 泄漏。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别靠 “消费者关 channel” 来通知生产者——Go 不允许向已关闭的 channel 发送数据，会 panic
- 用
sync.WaitGroup让主协程等待所有生产者完成，再关闭 channel：close(ch)只在所有生产者调用wg.Done()后由主协程执行 - 消费者侧用
for x := range ch安全读取，channel 关闭后自动退出循环
缓冲区大小选 64、128 还是 1024？看实际吞吐节奏
没有通用最优值。设成 1024 对日志采集可能合适，对实时风控决策就是灾难——延迟不可控。关键看两个节奏差：生产者平均间隔 vs 消费者平均处理耗时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
runtime.ReadMemStats观察 channel 缓冲区真实占用峰值，而不是拍脑袋设值 - 如果消费者处理时间波动大（比如依赖外部 HTTP），缓冲区宁小勿大，配合超时 + 重试更可控
- 注意 GC 影响：大缓冲区存大量指针对象（如
chan *MyStruct）会拖慢垃圾回收，优先用值类型或预分配对象池
真正麻烦的不是怎么设缓冲区，而是当消费者卡住时，你根本收不到信号——channel 本身不暴露阻塞状态，得靠外部指标（如 prometheus counter 滞后数）来诊断。
