select 默认是阻塞的：它会一直等待，直到至少有一个 case 的通信操作（如 channel 收发）就绪；若添加 default 分支，则变为非阻塞。
select 会阻塞还是非阻塞？取决于有没有 default
Go 的 select 默认是阻塞的：它会一直等，直到至少有一个 case 的通信操作（如 ch 或 <code>）可以立即完成。如果你不希望卡住，必须显式加 <code>default 分支——这时它变成非阻塞的“尝试一次”模式。
- 没
default：所有case都不可达时，goroutine 永久阻塞（常见于主 goroutine 中导致程序 hang 住） - 有
default：哪怕所有 channel 都没准备好，也会立刻执行default，不会等待 - 多个
case同时就绪时，select随机选一个执行（不是按书写顺序），这是设计使然，不能依赖顺序
如何用 select 实现超时控制？别漏掉 time.After
最典型的应用就是给 channel 操作加超时。核心是把 当作一个可接收的 channel 放进 <code>case，和业务 channel 并列。
select {
case msg := <-ch:
fmt.Println("收到:", msg)
case <-time.After(3 * time.Second):
fmt.Println("超时了")
}-
time.After返回的是，只能接收，不能发送，正好匹配 <code>select的接收语法 - 不要用
time.Sleep+ 单独 goroutine 模拟超时——那会多开协程、难管理、且无法取消 - 如果需要可取消的超时（比如外部主动终止），应改用
context.WithTimeout，配合使用
select 能监听多个 channel 吗？能，但不能重复写同一个变量名
可以同时监听任意数量的 channel，但每个 case 必须是独立的通信操作。常见错误是想在多个 case 中复用同一变量接收值，却忘了 Go 不允许重复声明：
// ❌ 错误：v 在多个 case 中重复声明
select {
case v := <-ch1: // 这里 v 是新声明
case v := <-ch2: // 这里又声明了一次 v，编译报错
}- 正确做法：在
select外声明变量，或每个case用不同变量名 - 更推荐的方式是把逻辑拆到函数里，避免变量名冲突，也提升可读性
- 如果多个 channel 类型相同、语义相近（比如都是
int），可以用一个统一的接收变量，但要确保只在一个case中赋值
空 select{} 是什么？慎用，它会让 goroutine 永久休眠
select{} 是合法语法，但它没有 case，也没有 default，因此会永远阻塞。它常被用作“让 goroutine 停住不动”，比如在 main 函数中防止程序退出：
立即学习“go语言免费学习笔记（深入）”；
go func() {
// 启动一些后台任务
}()
select{} // 主 goroutine 卡在这，整个程序不退出- 这招简单粗暴，但掩盖了真正的生命周期管理问题；生产代码更推荐用
sync.WaitGroup或context控制退出 - 测试中偶尔用来模拟长期运行的 goroutine，但上线前最好替换成可关闭的模型
- 绝对不要在循环里写
select{}，那等于死循环 + 阻塞，CPU 不占但资源锁死
实际写 select 时，最容易忽略的是「没有 default 时的阻塞风险」和「多个就绪 case 的随机性」——这两点不注意，轻则逻辑偶发错乱，重则整条 goroutine 归零。
