select语句必须配合channel使用，单独写会编译失败；它专为channel通信设计，非switch或for变体；select{}无case ch会导致死锁。
select 语句必须配合 channel 使用，单独写会编译失败
Go 的 select 不是 switch，也不是 for 的变体，它专为 channel 通信设计。如果你写了 select {} 却没在分支里写 case ch 或 <code>case v := ，Go 编译器会直接报错：<code>select statement with no cases。
常见误用：想“等待任意一个 goroutine 完成”，却忘了每个 case 必须绑定到一个 channel 操作上。没有 channel，就没有 select 的存在意义。
- 所有
case分支必须是 channel 发送或接收操作（ch 或 <code>） - 允许一个
default分支，用于非阻塞尝试；但没有default时，select会阻塞直到某个 channel 就绪 - 不能在
case中调用函数、赋值变量或写普通表达式——只允许 channel 操作
多个 channel 同时就绪时，select 随机选一个执行
Go 的 select 在多个 case 可立即执行时，并不按书写顺序选，而是**伪随机选择**。这不是 bug，是语言设计决定的，目的是避免隐式优先级和调度偏斜。
例如下面这段代码，ch1 和 ch2 都已缓存了值，但每次运行输出可能不同：
立即学习“go语言免费学习笔记（深入）”；
select {
case v := <-ch1:
fmt.Println("from ch1:", v)
case v := <-ch2:
fmt.Println("from ch2:", v)
}- 不要依赖 case 排序来控制逻辑优先级
- 如果真需要优先级（比如先处理控制信号再处理数据），把高优先级 channel 单独拎出来做一次 select，或用带
default的 select 轮询 - 测试时反复运行多次，才能观察到随机性——别因为某次结果固定就误以为有顺序保障
空 select{} 会永久阻塞，常用于“goroutine 永驻”场景
select {} 是 Go 里最短的永久阻塞写法，它会让当前 goroutine 挂起，且不消耗 CPU。这比 for {} 或 time.Sleep(time.Hour) 更干净。
典型用途是主 goroutine 等待信号退出，同时让子 goroutine 处理工作：
go func() {
// 处理任务...
}()
// 主协程停在这儿，不退出程序
select {}- 不能在主线程中用
for {}替代——那会 100% 占满一个 CPU 核 - 注意：如果所有 goroutine 都阻塞在
select{}或 channel 上，且无其他活跃 goroutine，程序会自动退出（Go runtime 检测到无 goroutine 可运行） - 搭配
signal.Notify时，常把信号 channel 塞进一个 select 里，而不是靠空 select 硬等
timeout 和 cancel 场景下，time.After 和 context.WithTimeout 的行为差异
处理超时，有人用 time.After(d)，有人用 context.WithTimeout。两者都能放进 select，但生命周期管理完全不同。
time.After 每次调用都会启动一个新 timer goroutine，即使你没从 channel 读取，它也会在超时后发送一次值然后退出——但若你 never read，timer 无法被 GC，长期运行会累积 goroutine。
而 context.WithTimeout 返回的 ctx.Done() channel，在 cancel 或 timeout 后能被复用、可检测、可传递，且不会泄漏 goroutine。
- 高频或长周期 select 中，优先用
ctx.Done()，尤其在 HTTP handler、RPC 调用等需传播取消信号的场景 -
time.After适合简单的一次性延时，比如“三秒后重试”，且确定一定会读取 - 别混用：
select中同时监听ctx.Done()和time.After是冗余的；用 context 就够了
实际写并发流程时，最容易被忽略的是 channel 的关闭时机和 select 的退出条件配合——channel 关了，但 select 还在等它，就会 panic；或者没关，但 sender 早退出了，receiver 死等。这些边界必须显式检查，不能靠“应该不会发生”来跳过。
