select语句必须至少有一个case，否则运行时panic死锁；空select{}非法，仅default合法非阻塞；多case就绪时随机选择，不保证顺序；函数调用在select前求值，可能引发阻塞。
select 语句必须至少有一个 case，否则会编译报错
Go 的 select 不是 switch 的变体，它专为通道操作设计，底层依赖于 goroutine 调度器的等待队列机制。如果写成空 select {}，程序会永久阻塞（deadlock），而写成只有 default 的 select 是合法的非阻塞轮询方式。
- 错误写法：
select {} // 编译通过，但运行时 panic: all goroutines are asleep - deadlock! - 正确轮询写法：
select { default: // 非阻塞，立即返回 } - 必须有可通信的 channel case 才能参与调度；
nilchannel 的 case 永远不会就绪（可用于临时禁用某路）
多个 case 同时就绪时，select 随机选择一个执行
Go 运行时不保证 case 的执行顺序，哪怕 ch1 总是先发数据、ch2 后发，只要两者在 select 执行瞬间都已就绪，选哪个完全随机。这避免了调度偏向和饥饿问题，但也意味着不能靠书写顺序做逻辑依赖。
- 常见误判场景：监听超时与数据通道，以为
time.After写在后面就“优先级低”，实际无意义 - 若需严格优先级（比如先响应取消，再处理数据），应拆成嵌套
select或用if select组合判断 - 调试时可通过反复运行观察不同输出，验证是否真被随机调度
case 中调用函数会导致意外阻塞或副作用
每个 case 表达式在 select 开始前就被求值，包括函数调用。如果函数内部有阻塞操作（如 http.Get、time.Sleep），整个 select 就卡住了——不是某个 case 卡住，而是整个语句无法进入等待状态。
- 错误示例：
select { case msg := <-ch: fmt.Println(msg) case <-time.After(expensiveFunc()): // expensiveFunc() 在 select 判定时就执行！ } - 正确做法：把耗时计算提到
select外，或用变量缓存结果：timeout := expensiveFunc() select { case msg := <-ch: fmt.Println(msg) case <-time.After(timeout): } - 尤其注意
make(chan int, 0)和make(chan int, 1)对读写行为的影响，可能让本该阻塞的 case 突然就绪
default 分支让 select 变成非阻塞轮询，但频繁空转消耗 CPU
加入 default 后，select 不再等待任何通道，每次执行都立刻走 default 或某个就绪 case。这适合事件驱动型服务（如游戏 tick、状态检查），但若没配合适当休眠，会变成忙等待。
立即学习“go语言免费学习笔记（深入）”；
- 典型陷阱：在 for 循环里写
select { default: doWork() }，CPU 占用飙到 100% - 缓解方式：default 中加
runtime.Gosched()让出时间片，或搭配短时time.Sleep(1ms) - 更优解：用带缓冲的 channel 做信号聚合，减少轮询频次；或改用
timer.Reset()复用定时器，避免反复创建time.After
实际用得多的其实是「带超时的通道读取」和「多通道合并监听」这两种模式，前者要小心 time.After 创建开销，后者要注意所有 channel 关闭后如何退出循环——select 本身不感知关闭，得靠 value, ok := 显式判断。
