select 会阻塞直到某个 case 准备就绪，本质是并发事件的同步等待机制；无 default 且所有 channel 不可操作时永久阻塞，多 case 就绪时运行时随机选择，仅支持 channel 操作或 default 分支。
select 会阻塞直到某个 case 准备就绪
Go 的 select 不是轮询，也不是条件判断，它本质是**并发事件的同步等待机制**。只要所有 case 中的 channel 操作都未就绪（比如向满 channel 发送、从空 channel 接收），select 就会一直阻塞——这点和 switch 完全不同。
常见错误是误以为 select 会“检查一遍然后跳过”，结果程序卡死在那。要避免阻塞，必须确保至少一个 case 能立即执行，或加上 default 分支。
- 没有
default且所有 channel 都不可操作 → 永久阻塞 - 多个
case同时就绪 → Go 运行时随机选一个执行（不是按书写顺序） -
case中不能写普通变量赋值或函数调用，只能是 channel 操作或default
带 default 的 select 实现非阻塞尝试
想“试试看有没有数据，没有就干别的”，就得靠 default。它让 select 变成非阻塞：只要没 channel 就绪，立刻执行 default 分支。
select {
case msg := <-ch:
fmt.Println("收到:", msg)
default:
fmt.Println("通道暂无数据")
}注意：default 不代表“超时”，它不等待；如果需要超时控制，得配合 time.After 或 time.NewTimer。
立即学习“go语言免费学习笔记（深入）”；
- 漏写
default却期望“快速返回” → 程序挂起 - 在循环中高频使用带
default的select→ 可能吃光 CPU（忙等） -
default分支里别放耗时操作，否则可能掩盖真实事件到达时机
用 select 实现超时与取消协作
真正的并发协调往往需要超时 + 取消。标准做法是把 和 <code> 都作为 <code>case 放进 select：
select {
case result := <-resultCh:
handle(result)
case <-time.After(2 * time.Second):
log.Println("请求超时")
case <-ctx.Done():
log.Println("上下文被取消:", ctx.Err())
}这里 ctx.Done() 是最稳妥的取消信号来源，比自己维护一个 done channel 更符合 Go 生态习惯。
- 用
time.Sleep替代time.After→ 编译不通过（类型不匹配） - 重复关闭同一个
context.CancelFunc→ panic - 忘记在
case 后 return 或 break → 可能继续执行后续逻辑，引发状态错乱
select 不能用于普通 channel 关闭检测
很多人想用 select 判断 channel 是否已关闭，但这是误区。对已关闭的 channel 执行接收操作不会阻塞，而是立即返回零值 + false，但这个行为发生在 case 内部，select 本身无法区分“有数据”和“已关闭但无数据”。
正确做法是在每个 case 接收后显式检查第二个返回值：
select {
case val, ok := <-ch:
if !ok {
fmt.Println("channel 已关闭")
return
}
fmt.Println("收到:", val)
}- 只写
val := → 无法知道 channel 是否已关，可能把零值误当有效数据 - 在
case外围用if ch == nil判断 → Go 不允许比较 channel 与 nil（编译报错） - 用
reflect检查 channel 状态 → 违反 Go 并发模型设计哲学，且不可靠
真正难的不是语法，是理解 select 的调度语义：它不承诺顺序，不保证公平，也不提供“事件优先级”。一旦混用超时、取消、多 channel，逻辑分支容易失控——建议每个 select 块只管一类协作目标，比如“等结果或超时”，而不是“等结果、等取消、等日志、等心跳”全塞一起。
