无缓冲channel必须由两个goroutine配对收发才能避免死锁；其本质是同步点而非数据管道，发送和接收需同时就绪，否则任一操作都会永久阻塞，典型错误是单goroutine中顺序执行发送与接收或仅发送未启动接收方。
channel 是 goroutine 之间通信的唯一安全、推荐且被运行时保障的方式。别试图用全局变量加锁模拟，那不是 Go 的玩法，反而容易触发 fatal error: concurrent map writes 或随机 panic。
无缓冲 channel 怎么用才不卡死
无缓冲 channel（make(chan T)）本质是“手递手”同步点：发送方必须等到接收方就绪，接收方也必须等到有数据可取，否则双方都阻塞。
常见错误现象：fatal error: all goroutines are asleep - deadlock!
- 主 goroutine 发完数据就退出，但没起接收 goroutine —— 比如只写
ch 却没配 <code>go func() { - 接收方提前 return，发送方还在循环发 —— 尤其在 for-select 中漏了
break或没处理done通道 - 在同一个 goroutine 里先发后收（无缓冲）：自己等自己，永远卡住
正确做法：确保收发在不同 goroutine；或用 select 配 default 做非阻塞试探；或改用带缓冲 channel 解耦节奏。
立即学习“go语言免费学习笔记（深入）”；
带缓冲 channel 的容量设多少才合理
缓冲区不是越大越好。设成 make(chan int, 1000) 看似“更稳”，实则掩盖背压问题：生产者狂塞、消费者慢吞，内存悄悄涨高，延迟不可控，还可能 OOM。
使用场景和建议：
- 日志采集：缓冲 128–1024，够撑住瞬时峰值，又不至于积压太久
- 任务队列：缓冲大小 ≈ 消费者并发数 × 平均单任务耗时 / 生产间隔，宁小勿大
- 纯通知（不传数据）：用
chan struct{}，零内存开销 - 不确定节奏时，优先用无缓冲 + 超时控制（
select { case ）
如何安全关闭 channel 并避免 panic
关闭 channel 的核心规则只有一条：仅由发送方关闭，且只能关一次。接收方关会 panic；重复关也会 panic。
典型误操作：
- 多个 goroutine 都调用
close(ch)—— 必 panic - 接收方在
for range ch里，但发送方忘了close(ch)—— 循环永不退出 - 关闭后还执行
ch —— <code>panic: send on closed channel
安全模式：
发送方做完所有发送后调用 close(ch)；接收方用 for v := range ch 自动退出，或用 v, ok := 判断是否已关闭（<code>ok == false 表示已关且无剩余数据）。
select 多路复用时为什么老选不到 default 分支
select 的 default 分支是唯一非阻塞出口，但它只在**所有 case 都不可立即执行时**才走。很多人以为 “加了 default 就不会阻塞”，其实不然 —— 只要任意一个 channel 当前可收/可发，select 就会立刻执行对应分支，跳过 default。
容易被忽略的细节：
- 无缓冲 channel 的发送/接收操作是否真“不可立即执行”？得看对方 goroutine 是否已就位
- 有缓冲 channel 的发送，在未满时永远算“可立即执行”，
default永远进不去 - 想强制非阻塞读？用
select { case v := ；但若 <code>ch是有缓冲且非空，case仍优先进入
真正需要兜底逻辑时，别依赖 default 掩盖设计缺陷，而应明确超时、关闭信号或状态检查。
复杂点往往藏在“谁负责关闭”和“谁该等待谁”上。哪怕代码只多起一个 goroutine，也要立刻问：它的生命周期由谁控制？它会不会成为孤儿 goroutine？channel 关不关、何时关、谁来关 —— 这些不是语法细节，而是并发契约。
