select 默认阻塞等待任一case就绪，无default时全阻塞，有default时非阻塞轮询；常见错误是遗漏default导致假死；超时常用time.After配合。
select 会阻塞，但不是所有 case 都要 ready 才能继续
很多人以为 select 必须等某个 channel 有数据才往下走，其实它会在所有 case 都阻塞时直接卡住——除非你加了 default。没加 default 的 select 就是纯阻塞式多路等待；加了就变成“非阻塞轮询”，哪怕所有 channel 都空着也会立刻执行 default 分支。
常见错误现象：select 看似“没反应”，程序停在那儿不动，其实是没写 default，又没任何 channel 可读/可写。
- 想做“尝试读取，不行就干别的”？必须带
default - 想等任意一个
channel就绪再处理？去掉default，但得确保至少有一个可能就绪，否则永远卡住 -
time.After常和select配合做超时，本质就是往一个定时channel写信号
示例：
select {
case msg := <-ch:
fmt.Println("收到：", msg)
default:
fmt.Println("现在没消息")
}
多个 case 同时 ready 时，select 随机选一个执行
select 不保证顺序，哪怕你把 case 写在最上面，只要 <code>ch1 和 ch2 同时有数据，它也可能挑 ch2。这不是 bug，是设计使然——避免隐式优先级导致的饥饿或耦合。
使用场景：当你要公平调度多个输入源（比如多个客户端连接、多个任务队列），这个随机性反而是优点；但如果你依赖“先检查 A，A 不行再试 B”，那就不能靠 select 结构本身，得拆成独立判断。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别用
select实现“优先级队列”，改用显式if+select组合 - 测试时看到执行顺序不一致？正常，不是环境问题
- 性能影响极小，随机开销可忽略，但心理预期要调过来
case 中不能直接对 channel 做赋值或复杂表达式
select 的每个 case 后面只能跟一个通信操作：要么 ，要么 <code>ch ，不能带条件、函数调用或变量声明。比如 <code>case x := 是非法的，<code>case 虽然合法，但每次都会新建一个 <code>Timer，容易泄漏。
常见错误现象：invalid operation: := (no addressable left-hand side) 或 goroutine 泄漏（大量未 stop 的 timer）。
- 接收并赋值要写在
case内部，如case msg := 是对的，但 <code>case v = 不行 - 超时控制别在
case里写time.After，提前定义好timer := time.NewTimer(d)，用，用完记得 <code>timer.Stop() - 发送操作同理，
case ch 会先执行函数再等 channel 就绪，可能造成意外延迟
nil channel 在 select 中永远阻塞，可用来动态开关 case
把一个 channel 设为 nil，它在 select 里就彻底“消失”了——既不会被选中，也不会导致 panic。这是 Golang 官方文档里明确写的技巧，用来实现运行时启用/禁用某个监听路径。
使用场景：热插拔监听器、按需开启调试通道、状态驱动的事件分流。
- 初始化时设
var debugCh chan string（即nil），需要时再debugCh = make(chan string, 10) - 关闭后别忘了再置
nil，否则已关闭的 channel 会立即触发case（读返回零值，写 panic） - 注意：nil channel 和 closed channel 行为完全不同，别混为一谈
这事看着小，但线上出问题时，最容易被忽略的就是某个 channel 被意外置 nil 或忘记重置，结果监听悄无声息地断了。
