select分支执行顺序是伪随机轮询而非随机或按代码顺序；当多个case就绪时，Go以per-Goroutine伪随机起始索引轮询，防饿死但不可预测；default优先级最高，仅有一个case就绪则直接执行，全阻塞则goroutine挂起。
select 分支执行顺序不是随机的，而是伪随机轮询
Go 的 select 在多个 case 都就绪时，并不会按代码书写顺序选第一个，也不会真随机挑一个——它底层用的是带偏移的轮询（per-Goroutine 的伪随机起始索引），目的是避免某些 case 长期饿死。但这个“伪随机”对开发者不可控、不可预测，也不该依赖。
常见错误现象：select 总是先触发某个 case，误以为写在前面就优先；或者反复测试发现顺序“变来变去”，以为是 bug。
- 真正就绪的
case数量 ≥ 2 时，调度器才启动轮询逻辑；只有一个就绪，直接执行它 -
default分支永远最高优先级：只要存在且无阻塞，就立刻执行，不参与轮询 - 如果所有
case都阻塞（包括default不存在），goroutine 挂起，直到至少一个就绪
为什么不能靠 select 实现“公平分发”或“负载均衡”
因为 select 的轮询只是防止饿死的底层机制，不是设计用来做业务层调度的。它的伪随机性不保证均匀分布，也不感知 channel 负载、消息大小或处理耗时。
使用场景误区：有人用 select 往多个 worker channel 发任务，指望自动“打散”；结果某 worker 持续收到更多任务，另一些空闲。
立即学习“go语言免费学习笔记（深入）”；
- channel 的缓冲区长度、接收方是否及时消费，会极大影响哪个
case更容易就绪 - GMP 调度器本身不介入
select决策，它只管 goroutine 唤醒和抢占，不干预分支选择逻辑 - 若需真正公平，应显式维护队列、计数器或用
sync/atomic做轮询索引，而不是依赖select
调试 select 行为：如何确认哪个 case 先被选中
没有内置 debug 工具能直接打印 select 的决策路径，但可以通过加日志 + 强制阻塞来观察行为模式。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
示例：想验证两个 chan int 同时就绪时谁被选中
ch1 := make(chan int, 1)
ch2 := make(chan int, 1)
ch1 <- 1
ch2 <- 2
select {
case <-ch1:
fmt.Println("ch1")
case <-ch2:
fmt.Println("ch2")
}这段代码每次运行输出不确定，但重复 100 次后会发现大致接近 50/50——这不是“随机”，而是 runtime 对当前 goroutine 的轮询种子不同导致的分布。
- 不要用
time.Sleep模拟就绪，容易引入竞态，改用带缓冲 channel 或close()触发 - 注意：
go tool trace可看到 goroutine 阻塞/唤醒事件，但看不到select内部选分支的细节 - 若需确定性行为，唯一可靠方式是把多路复用逻辑收归一个 channel，由单独 goroutine 统一分发
容易被忽略的边界：nil channel 和关闭 channel 的 select 行为
nil channel 在 select 中永远阻塞；已关闭的 recv channel 立即返回零值；已关闭的 send channel 则 panic。这三者混合时，行为极易出错。
常见错误现象：向已关闭的 chan struct{} 发送导致 crash；或误判 select “跳过”了某个 case，其实是它对应的 channel 是 nil。
case 这个分支永远不触发，等价于删掉case ch 若 <code>ch已关闭，运行时报panic: send on closed channelcase x := 立即返回 <code>x == zero value且ok == false（仅对带 ok 的接收有效）
真正难缠的是那种动态赋值为 nil 或中途关闭的 channel，它们让 select 行为随生命周期变化，比轮询逻辑更难推理。
