select中匿名函数或http.get等阻塞调用会立即执行导致卡死，因其在select求值阶段而非case选中时运行；正确做法是将耗时操作移至select外并用channel通信。
Go 的 select 不是系统级 I/O 多路复用，它只协调 channel；所谓“非阻塞 IO”，本质是把 IO 封装成 channel 后再用 select 做非阻塞探测。
为什么 select 里写 http.Get 会卡死
因为 case 右边的表达式在进入 select 的**瞬间就求值**，不是等到该 case 被选中才执行。如果写成 case res := ，而 <code>doHTTP() 内部调用了 http.Get，那整个 goroutine 在 select 开始前就已阻塞。
- 正确做法：把耗时操作提到
select外，例如先调http.Get得到响应或错误，再把结果发到 channel - 更常见模式：用 goroutine 封装 IO，如
go func() { res, _ := http.Get(url); ch ，让 <code>select只管收 - 切忌在
case中直接调用任何可能阻塞的函数（time.Sleep、database.Query、os.ReadFile等同理）
default 不是超时，是“此刻无事可做”的立即返回
很多初学者把 default 当作超时分支，结果写出高频空转逻辑。它不启动计时器，也不等待，只表示“所有 case 当前都无法立即完成”。
- 典型误用：
for { select { default: doWork() } }→doWork()每秒被调上千次，CPU 拉满 - 真正超时必须用定时 channel：
case 或更安全的 <code>timer := time.NewTimer(5 * time.Second); defer timer.Stop() -
default的合理用途：轮询检查某个 channel 是否有数据（如心跳包接收），但需搭配time.Sleep控制频率
多个 case 同时就绪时，执行顺序完全随机
哪怕你把退出通道 quitCh 放在第一个 case，只要它和 dataCh 在判定瞬间都已就绪，Go 就可能选 dataCh 执行。这不是 bug，是防饥饿机制。
- 无法靠书写顺序控制优先级
- 需要强优先级响应（如必须先处理取消）？拆成嵌套
select：select { case - 调试时多跑几次，输出顺序跳变，就是被随机调度了——这是正常行为，不是逻辑错误
空 select{} 会立刻 panic 死锁
这不是“暂停”，而是让当前 goroutine 永久休眠。一旦所有 goroutine 都卡在这里，运行时马上报 fatal error: all goroutines are asleep - deadlock!。
- 编译期不报错，运行期爆炸，极难排查
- 想等子 goroutine 结束？用
sync.WaitGroup或向一个已关闭的donechannel 接收 - 真要阻塞等待某个事件？写成
select { case ，其中 <code>done是由其他 goroutine 关闭的 channel
最易被忽略的一点：channel 是否就绪，取决于「此刻能否零延迟完成操作」，而不是「有没有数据」。比如对一个未关闭的无缓冲 channel 执行 ，若没有 goroutine 在另一端等待接收，它就不就绪——哪怕你刚往里面 send 过，也无效，因为没配对。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
