go 的 select 不保证公平分发，仅防饿死；多个就绪 case 不按代码顺序执行，因运行时用 goroutine 哈希种子伪随机打乱顺序后取首个可执行项。
Go 的 select 不保证公平分发，它只防饿死，不保均匀；依赖它做负载均衡或优先级控制，一定会出问题。
为什么多个就绪的 case 不按代码顺序执行
因为 Go 运行时根本不会线性扫描 case 列表。当两个或更多 case 同时就绪（比如两个带缓冲的 chan 都有值），select 底层会用当前 goroutine 的哈希种子打乱 case 顺序，再线性查找第一个可执行项——这个“打乱”是伪随机、不可预测、也不跨 goroutine 复现的。
- 写在前面的
case 可能永远不被选中，尤其在压测或加日志后行为突变 - 这不是 bug，是设计：Go 文档明确写 “if multiple cases are ready, it chooses one at random”
- 真正影响“谁先就绪”的，是 channel 缓冲区长度、接收方是否已启动、甚至调度器抢占时机
default 分支如何彻底改变 select 行为
default 不是“备选”，而是非阻塞开关：只要存在，select 就绝不会挂起；但它不参与“多就绪竞争”，只在所有 case 全部阻塞时才触发。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 无缓冲
chan上的或 <code>ch 在无人配对时必然阻塞 → 直接进 <code>default - 哪怕只有一个
case就绪，default就完全不会执行 - 常见误用：在
default里写重试逻辑，期望“下次循环就能命中某case”，但实际可能连续百次都走default，因为就绪性没变
如何验证 select 实际选择了哪个 case
不能靠单次运行猜，必须构造确定就绪态 + 统计分布：
- 用
make(chan int, 1)创建缓冲通道，提前写入值，确保收发操作 100% 立即就绪 - 避免用
go func(){ ch 触发发送——goroutine 启动时机不可控，导致就绪时间飘移 - 跑 1000 次循环，统计每个
case命中次数；偏差超过 ±5% 就说明环境干扰大（如 GC 抢占、系统负载） - 别信
fmt.Println日志顺序：打印本身有延迟，可能掩盖真实调度路径
真正需要公平调度时该怎么做
把公平性从运行时搬到业务层：用显式状态代替隐式轮询。
- 维护一个轮询索引
atomic.Int32，每次取模递增，决定下一个 worker channel - 用
sync.Pool缓存预分配的select结构体（含多个case），避免每次重建开销 - 对高吞吐场景，直接放弃
select，改用chan+for range+context控制生命周期 - 如果必须多路监听且要权重，就别用
select，改用runtime.Gosched()配合状态机轮询
最易被忽略的点：select 的“公平”仅作用于就绪瞬间的分支选择，它对 channel 背后的 goroutine 负载、处理耗时、缓冲区水位毫无感知——这些才是生产环境不均的真正根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
