无缓冲 channel 卡死是因为其同步握手机制要求发送与接收必须同时就绪；主线程写入时若无协程立即接收，就会阻塞。
为什么无缓冲 channel 一用就卡死？
因为无缓冲 chan 的设计就是“同步握手”——发送和接收必须在同一时刻就绪，缺一不可。不是 bug，是契约；但业务代码里几乎从不想要这种强耦合。
- 主线程写
ch ，没起 goroutine 读 → 立即死锁，程序 panic - 消费者 panic 后退出，没关
ch，生产者还在发 → 缓冲满后永久阻塞 -
for range ch遍历未关闭的 channel → 循环卡住，永远不会退出
解决思路不是“避免用无缓冲”，而是明确场景：只在需要精确同步（比如初始化完成信号、goroutine 启动确认）时才用；其余一律默认考虑带缓冲。
缓冲区设多大才不浪费又不卡住？
不是拍脑袋填 1024 或 runtime.NumCPU()，而是按真实吞吐节奏算出来的数字。
- 典型批次大小 × 1.5～2 倍：比如日志每秒写 120 条，消费延迟均值 60ms → 瞬时积压约 7～8 条，缓冲设
16足够应对抖动 - 容量
几乎等效于无缓冲，仍频繁阻塞；>= 10000内存涨得快，还掩盖了消费者慢的真实问题 - 运行时可用
len(ch)查当前排队数，cap(ch)看上限，别等 OOM 才发现缓冲设歪了
select + default 不是万能解药，小心 CPU 空转
非阻塞收发确实能跳过阻塞，但滥用会导致 goroutine 在空循环里狂占 CPU。
立即学习“go语言免费学习笔记（深入）”；
- 正确姿势：
select { case ch —— 加休眠，别裸跑 - 适合场景有限：日志上报、埋点采集这类“丢了不重试”数据；关键业务流（如订单入队）不能靠
default忽略失败 - 永远别在 HTTP handler 或定时任务里写无限
for { select { ... } }，没超时、没取消，goroutine 就再也收不回来
超时、关闭、context，三者缺一不可
阻塞本身不可怕，可怕的是没有退出路径。一个没被 cancel 的 goroutine，就是内存里的钉子户。
- 发数据前必加超时：
select { case ch - channel 关闭责任必须清晰：只由发送方调用
close(ch)；接收方通过v, ok := 判断是否已关 - 跨 goroutine 协作务必传
context.Context：用context.WithTimeout控制单次操作，context.WithCancel支持手动中断
最常被忽略的一点：阻塞不是要“消灭”，而是要“驯服”——让它在可控时间、可控路径下发生，而不是任由它把整个 goroutine 拖进黑洞。
