go 的 select 不支持权重或轮询，多个就绪 channel 会随机选择执行；default 仅用于非阻塞试探，高频轮询须用 time.ticker；case 表达式在 select 开始前即求值，耗时操作需提前缓存。
select 本身不支持权重或轮询
Go 的 select 语句没有“权重”概念，也不会按书写顺序优先尝试某个 case。当多个 channel 同时就绪时，运行时会随机挑选一个执行——这是防饥饿的主动设计，不是 bug，也不是可配置的行为。
常见误判场景：
- 把高优先级 channel 写在前面，以为它“更容易被选中”
- 用
for { select { default: } }模拟轮询，结果 CPU 100% - 在
case中调用耗时函数（如time.After(expensiveFunc())），导致整个select卡住
真正需要周期性探测（比如心跳、健康检查），必须用 time.Ticker 或 time.NewTimer 配合 select，而不是靠 default 硬撑。
高频轮询必须用 time.Ticker，不能靠 default 空转
default 的唯一合法用途是“非阻塞试探”，比如快速判断某个 channel 是否有数据可读，而不是用来实现周期性行为。
错误写法：
for {
select {
default:
// 每次都立刻进来，CPU 疯狂空转
}
}
正确做法：
- 用
ticker := time.NewTicker(1 * time.Second)控制节奏 - 在
select中监听，而非 <code>default - 退出前务必调用
ticker.Stop()，否则 goroutine 泄漏
如果要带超时控制，优先用 context.WithTimeout，让下游 API（如 http.Client.Do、sql.DB.QueryContext）自动消费，避免手动管理 timer 生命周期。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真要模拟“优先级”，得结构上隔离，不是靠 case 排序
想让控制信号（如 quit）比数据通道（如 dataCh）更快响应？别指望把 case 写在前面就能生效。
可行方案：
- 单独起一个
select专门处理高优 channel，带default快速试探；没命中再进主select - 用嵌套
if select：先试一次quit，没数据再试dataCh，但注意这已不是并发，是串行探测 - 对每个 channel 单独起 goroutine +
time.After控制间隔，结果汇总到统一 channel——只适合低频场景，开销大
所有这些方案都不是“给 select 加权重”，而是绕过它，用结构换确定性。
case 表达式在 select 开始前就被求值
这个细节常被忽略：case 中的 <code>someFunc() 会在 select 进入等待前就执行，哪怕最终根本没走到那个分支。
典型陷阱：
case ：每次循环都连一次 DB，不管是否真要用case msg := ：如果 <code>ch是无缓冲 channel，且没人发，这个case就永远阻塞——但你可能误以为是别的 case 没触发
安全写法：
- 把耗时计算提到
select外，用变量缓存结果 - 用
nilchannel 临时禁用某路：var ch chan int; select { case v := ，<code>ch == nil时该分支永远不就绪
最隐蔽的问题往往出在这里：你以为 select 是“懒求值”的，其实它很早就把所有 case 表达式全算完了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
