select 语句必须包含至少一个 case，否则会永久阻塞；空 select{} 将导致 goroutine 不可恢复挂起，无法被 runtime.Goexit() 唤醒，易引发资源泄漏。
select 语句必须包含至少一个 case，否则会永远阻塞
Go 的 select 不是轮询或条件判断，而是纯粹的通道操作调度器。空 select（即没有 case）会导致 goroutine 永久挂起，且无法被外部中断——这在超时控制或资源清理场景下极易引发泄漏。
- 错误写法：
select {}—— 程序卡死，
runtime.Goexit()也无法唤醒 - 正确做法：至少配一个
case 或default分支 - 若仅需“等待任意一个通道就绪”，必须显式列出所有目标通道，不能动态构造
default 分支让 select 变成非阻塞，但容易掩盖逻辑错误
default 让 select 立即返回，看似避免阻塞，实则可能跳过本该处理的消息。尤其在循环中滥用 default，会导致 CPU 空转或消息积压。
- 适合场景：做快速探测（如检查通道是否空闲）、实现带退避的重试逻辑
- 危险场景：替代超时机制（应优先用
time.After+ 单独case） - 典型误用：
for { select { case msg := <-in: handle(msg) default:>
case 中不能直接对 channel 变量赋值或修改
select 的每个 case 必须是通道操作表达式（ 或 ch ），不能混入变量赋值、函数调用等副作用语句。Go 编译器会报错：invalid operation: cannot assign to receive from …。
- 错误写法：
select { case x = <-ch: > - 正确写法：先接收，再处理
select { case val := <-ch: > - 注意：
val是case内部作用域变量，不能跨 case 使用
多个可就绪 case 时，Go 随机选择，不可预测
当多个 case 同时满足（比如多个缓冲通道非空、多个发送方就绪），select 不按书写顺序执行，而是伪随机挑选——这是为避免饿死和隐藏调度依赖，但也意味着你不能靠排列顺序控制优先级。
立即学习“go语言免费学习笔记（深入）”；
- 如果业务需要严格优先级（如日志通道 > 数据通道），必须拆成嵌套
select或加锁协调 - 常见陷阱：用
select实现“主备通道”时，误以为先写的case会被优先选中 - 验证方式：在高并发压力下运行多次，观察不同 case 的触发比例是否接近均匀分布
实际写多路复用时，最常被忽略的是 通道关闭状态未检查：从已关闭的 channel 接收会立即返回零值，且不会阻塞；但若没配合 ok 判断，就会把零值当有效数据处理。这个细节在组合多个通道时极难调试。