select 专用于监听多个 channel 的读写就绪状态，哪个就绪就执行对应 case；无就绪且无 default 则阻塞；它不能用于普通变量或函数调用，因其底层依赖 runtime 对 channel 的轮询、sudog 调度与 selectgo 协作机制，且编译器强制要求所有 case 必须是 channel 通信操作。
select 不是 switch，它只做一件事：监听多个 channel 的读写就绪状态，哪个 ready 就执行哪个，没有就绪且无 default 就阻塞。
select 为什么不能用在普通变量或函数调用上
因为 select 的底层依赖 runtime 对 channel 状态的轮询和调度，它被编译器特殊处理，所有 case 必须是 channel 操作（、<code>ch ），其他表达式会直接报错：
-
case x == 5:→ 编译失败：“non-channel type” -
case fmt.Println("hi"):→ 编译失败：不是通信操作 case → 运行时 panic：“send on nil channel” 或死锁
它的设计目标明确：仅协调 goroutine 间基于 channel 的同步与 IO 多路复用，不承担逻辑分支职责。
没有 default 时 select 阻塞的典型表现
当所有 case 对应的 channel 都未就绪（空读 / 满写），且没写 default，当前 goroutine 会挂起，不释放 CPU，但也不消耗资源——这是“协作式阻塞”，由 runtime 统一管理唤醒。
- 常见错误：在主 goroutine 写
select {}→ 程序立即 deadlocked - 调试线索：
fatal error: all goroutines are asleep - deadlock! - 正确做法：确保至少有一个 goroutine 向被监听的 channel 发送/接收数据，或加
default做 fallback
多个 case 同时就绪时为何不按顺序执行
select 为避免 channel 饥饿，内部使用随机轮询顺序（pollorder）+ 固定加锁顺序（lockorder）双重机制。即使 case 在代码里从上到下排列，执行顺序也是伪随机的。
- 这意味着：
case 和 <code>case 都 ready 时，不会总是先选 ch1 - 不能依赖顺序做业务逻辑（比如“优先处理 A，其次 B”），需改用带优先级的 channel 设计或额外控制逻辑
- 测试时若发现行为不稳定，不是 bug，而是预期行为
for 循环里套 select 的常见陷阱
把 select 放进 for 是持续监听的标准写法，但容易忽略两个关键点：
-
break只跳出select，不会退出for—— 想终止监听必须用return或带标签的break - 如果某个
case执行耗时较长（如网络请求、文件写入），会阻塞整个select轮次，影响其他 channel 响应及时性；应把重操作挪到 goroutine 里 - 频繁空
default（比如每毫秒轮询）会导致 CPU 占用飙升，此时应结合time.After或time.Tick控制节奏
真正难的不是语法，而是判断什么时候该阻塞、什么时候该非阻塞、以及如何让多个 channel 的响应节奏互不干扰——这需要结合具体 IO 特性来权衡，不是套模板能解决的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
