Go的select在多个case同时就绪时采用伪随机轮询，底层以goroutine地址和单调时钟为seed哈希打乱就绪case索引后线性扫描选首个，旨在防饿死而非保证业务公平；就绪指channel操作能无阻塞立即完成。
select多个case就绪时到底怎么选
Go的select在多个case同时就绪时，并不按代码顺序执行，也不是真随机，而是用per-Goroutine伪随机起始索引轮询——每次运行可能不同，但同一goroutine重复调用时分布也不均匀。它只为防饿死，不是为业务公平性设计。
- 就绪（ready）是硬门槛：比如
能立即返回值（ch有数据或已关闭），<code>ch 能立刻写入（ch有空缓冲或有接收方在等） - 只要有一个case就绪，其他是否就绪都不影响结果；只有≥2个就绪，才触发轮询逻辑
- 轮询种子由runtime内部生成，开发者无法控制、不可预测，也不该在逻辑中依赖
default分支为什么总是“插队”成功
default不是和其他case一起参与随机选择，而是优先级最高——只要它存在且自身不阻塞（它从来不会阻塞），就直接跳过所有channel评估，立刻执行。
- 这是
select实现非阻塞探测的唯一合法方式：没有default，select会挂起goroutine；有default，哪怕所有channel都空/满/无协程配对，也会立即走default - 常见误用：把
default当“兜底重试”，却没意识到它和channel操作完全不在一个调度层级上 - 注意：
default里不能放耗时操作，否则会掩盖真实channel就绪信号，变成“假非阻塞”
为什么你写的select总走同一个case
不是runtime有问题，而是你误判了“就绪”——绝大多数看似“随机失效”的情况，其实只有一个case真正就绪，其余全阻塞。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 无缓冲channel的
：必须有goroutine正在另一端<code>ch ，才算就绪；光往里面<code>close(ch)不算，除非ch已关闭且有数据或零值可读 - 发送操作
ch ：若ch是带缓冲的，得看len(ch) 上等待 - 典型陷阱：启动goroutine往channel发数据，但没加
time.Sleep或sync.WaitGroup确保它真跑起来，导致select执行时发送方还没开始，所有发送case全阻塞
想真正公平分发任务？别靠select
用select往多个worker channel发任务，指望自动打散，结果负载倾斜严重——这不是bug，是机制必然。
立即学习“go语言免费学习笔记（深入）”；
- channel缓冲区长度、接收方消费速度、goroutine调度时机，都会影响哪个case更容易“碰巧就绪”
- runtime不感知业务语义：它不管消息大小、处理耗时、worker当前负载，只看瞬时I/O能否完成
- 正确做法：显式维护轮询索引（
atomic.Int64）、用sync.Pool缓存任务、或引入中间队列+权重调度，而不是把调度责任推给select
真正容易被忽略的点是：就绪判定发生在select语句执行的那一纳秒快照，不是未来某个时间点。它不等待，不预测，不调度——只响应此刻能零延迟完成的操作。
