空 select{} 会触发运行时死锁 panic，因无可用 channel 且无 default 分支，导致所有 goroutine 休眠；它语法合法但执行必崩溃，需确保至少一个非 nil channel case 或使用 default 避免阻塞。
空 select{} 会立即 panic，不是语法错误，而是运行时死锁 —— 这是 Go 并发最基础也最容易翻车的陷阱之一。
为什么 select{} 编译通过却必 panic
Go 编译器不检查 select 是否有可通信的 case，只检查语法结构。空 select{} 合法，但 runtime 发现当前 goroutine 没有任何通道可等待、又没 default 分支，就会判定“所有 goroutine 都在睡觉”，触发 fatal error: all goroutines are asleep - deadlock!。
- 它和
for{}不同：后者是 CPU 空转，前者是彻底阻塞 + 崩溃 - main goroutine 中写
select{}，程序启动即挂；子 goroutine 中写，该 goroutine 永久卡住，可能拖垮整个逻辑流 - 常见于“想让主 goroutine 留着不退出”时随手写的错误兜底
select 必须至少有一个非 nil 的 channel case
哪怕你只是想“等任意一个通道就绪”，也得确保每个 case 对应的 channel 不是 nil。因为 nil channel 的 case 永远不会就绪，相当于“假装存在，实际消失”。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
ch := make(chan int)是合法的，ch := (chan int)(nil)或未初始化的var ch chan int就是nil - 如果动态构造
select（比如从 slice 构建多个case），要提前过滤掉nilchannel，否则该路永远无效 - 用
if ch != nil判断再进select是安全做法，但注意：判断和select之间 channel 可能被关掉，所以不能完全替代运行时检查
用 default 实现非阻塞轮询，但别滥用
只有 default 的 select 是唯一合法的“空等待”形式，它立刻返回，不阻塞。但它不是万能解药 —— 它把 select 变成忙循环。
- 高频轮询（比如每毫秒一次）会吃光单核 CPU，尤其在无事可做时
- 典型误用：在 for 循环里反复跑
select { default: time.Sleep(1 * time.Millisecond) }—— 这不如直接time.Sleep - 真正适合场景：事件驱动中需要“快速试探是否就绪”，比如尝试读缓冲区、检查取消信号、做轻量级状态快照
- 若需等待超时，优先用
time.After而非轮询：select { case
函数调用在 select 开始前求值，这是隐藏雷区
所有 case 表达式（包括函数调用）会在进入 select 逻辑前全部执行完毕。如果某个函数阻塞或耗时，整个 select 就卡在门口，根本没机会等通道。
- 错误写法：
case → <code>someSlowFunc()先执行，卡住 - 正确写法：先把结果算出来，再进
select：timeout := someSlowFunc(); select { case - 同理，
case data := 中的 <code>ch变量如果是函数返回值，也要提前接住，避免函数调用嵌在 case 里 - 调试时可加日志验证：在函数开头打点，你会发现它总在 select 输出前就打印了
真正难的不是写对 select 语法，而是在并发流程中判断“此刻该等什么、不该等什么、等不到时怎么办”。nil channel、default 频率、函数副作用，三者叠加最容易漏查 —— 它们不会报编译错，但会让程序在特定负载下突然卡死或狂占 CPU。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
