select本身不支持轮询，default不是轮询开关；看似轮询实为CPU空转，应使用time.Ticker配合select实现周期性探测，default仅用于非阻塞试探。
select 本身不支持轮询，default 不是轮询开关
写 for { select { default: ... } } 看似在“轮询”，实则是 CPU 空转。它没等任何事件，每轮都立刻进 default，不做任何等待或让出调度权。Go 不提供隐式轮询机制，这种写法只会把 goroutine 变成忙等线程。
- 真正需要周期性探测（比如检查健康状态、轮询 DB 连接），该用
time.Ticker配合 select，而不是靠default撑场 -
default的唯一合法用途是“非阻塞试探”：例如select { case x, ok := - 若误用于长循环，会掩盖真实阻塞点，且难以压测复现——本地跑得飞快，上线后 CPU 直接拉满
select 分支没有权重，多个就绪时 runtime 随机选择
把高优先级通道写在前面，不会让它被更早选中。当 ch1 和 ch2 同时有数据，select 调用 runtime.selectgo 时会 shuffle 所有就绪 case 的索引，再线性扫描，结果不可预测。
- 这不是 bug，是防饥饿的主动设计：避免某个 channel 总是“插队”，导致其他通道饿死
- 测试时总看到同一个 case 先触发？大概率是发送时机/缓冲区状态导致它总是先就绪，不是书写顺序生效
- 真要区分响应等级，必须结构上隔离：高优通道单独一个 select（可加
default快速试探），低优通道放另一个 select + timeout
想模拟轮询顺序？别改 select，改 channel 构建方式
硬要在多个通道间按固定顺序尝试，select 不是解法。它的语义是“任一就绪即处理”，不是“依次检查”。强行模拟顺序轮询，反而破坏并发本意，还引入隐藏竞争。
- 用
if select { case ... }嵌套链：先试chA，没数据再试chB，依此类推 —— 但注意这已不是并发，是串行探测 - 对每个 channel 单独起 goroutine +
time.After控制探测间隔，结果汇总到统一 channel —— 开销大，仅适合低频场景 - 高频轮询需求（如设备状态采集），应换用
time.Ticker定期广播信号，各 worker 自行决定是否响应，而非靠 select “抢答”
高频重试或心跳场景，time.After 必须换成 time.NewTimer
循环里写 case ，每次都会 new 一个 timer，且不触发就不会被 GC。压测几分钟，几百个滞留 timer 就能吃光内存。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：在循环外初始化
timer := time.NewTimer(d)，每次 select 后调timer.Reset(d)，退出前timer.Stop() - 更省心的是统一走
context.WithTimeout：传入的ctx可被所有支持 context 的 API（http.Client.Do、sql.DB.QueryContext）自动消费，无需手动管理 timer 生命周期 - 特别注意：timer.Reset() 在 timer 已触发后调用才安全；若不确定状态，先
Stop()再NewTimer()更稳妥
复杂点在于，select 的随机性不是缺陷，而是运行时保障公平性的必要手段；想绕过它做“可控轮询”，本质上是在对抗 Go 的调度模型——不如退一步，用更贴近问题本质的结构（Ticker、嵌套 select、独立 goroutine）来表达意图。
