go 的 select 默认不按书写顺序或就绪先后选择 case，而是伪随机选择，以避免 goroutine 饥饿和隐式优先级依赖；多次运行同一 select 代码，输出顺序通常不同。
select 默认分支为什么不是“最先就绪就选它”
Go 的 select 语句不保证按 case 书写顺序或 channel 就绪先后执行，而是运行时伪随机选择——这是语言规范明确要求的，目的是避免 goroutine 饥饿和隐式优先级依赖。你写 select 时不能假设第一个 case 一定先跑，哪怕它对应的 channel 已经有值。
验证方式很简单：连续运行同一段代码多次，观察输出顺序是否变化。比如：
ch1 := make(chan int, 1) ch2 := make(chan int, 1) ch1 <p>实际输出可能是 <code>ch1</code>、<code>ch2</code>、<code>ch1</code>、<code>ch2</code>、<code>ch2</code> 这类混合序列，而非固定模式。</p><h3>runtime.selectgo 是如何实现伪随机的</h3><p>Go 运行时在 <code>runtime.selectgo</code> 中对所有就绪的 <code>case</code> 构建一个 slice，然后用 <code>uintptr(unsafe.Pointer(&c)) ^ uintptr(unsafe.Pointer(&s))</code> 类似的地址哈希（具体是基于 case 地址和当前 goroutine ID 的简单异或+移位）生成一个索引偏移，再取模得到起始扫描位置。不是真随机，但每次调度上下文不同，结果不可预测。</p><p>这意味着：</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4221" title="Golang Lint"><img src="https://img.php.cn/upload/skill/000/000/081/178996868679213.jpg" alt="Golang Lint" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill4221" title="Golang Lint" class="overflowclass">Golang Lint</a> <p class="overflowclass">Golang 项目 lint 最佳实践与 golangci‑lint 配置——运行 linter、编辑 .golangci.yml、使用 nolint指令抑制警告。</p> </div> <a rel="nofollow" href="/xiazai/skill4221" title="Golang Lint" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 同一段代码在不同 Go 版本、不同 GC 状态、甚至不同编译参数下，随机种子可能变化
- 即使两个 channel 同时就绪，
select也不会“轮询”或“公平调度”，只是从某个偏移开始线性扫描，选中第一个就绪项 - 没有配置项能关闭这个行为；
GODEBUG=asyncpreemptoff=1等调试变量不影响select逻辑
想控制执行顺序？别硬靠 select，换方案
如果你需要确定性行为（比如日志优先写入、超时必须先检查），select 不是工具。常见错误是反复 select + default 轮询，既浪费 CPU 又不解决问题。
更合理的做法：
- 用
if+select组合：先判断某个 channel 是否就绪（len(ch) > 0或用select { case x := 非阻塞探测），再决定是否进入 <code>select - 把高优先级逻辑拆到独立 goroutine +
time.After或context.WithDeadline控制时序 - 用带缓冲的 channel 模拟队列，配合单个
select消费，把调度逻辑移到生产端
例如，强制先处理 done 信号：
select {
case <h3>学习调度逻辑时最容易忽略的一点</h3><p>很多人以为 <code>select</code> 的“随机”是为了负载均衡，其实核心目标是消除隐式依赖——一旦开发者写出依赖执行顺序的代码，就等于把调度策略耦合进了业务逻辑，而 Go 的调度器本身不承诺任何顺序保证。真正影响性能的往往不是随机本身，而是你在多个 channel 上反复 <code>select</code> 却没考虑唤醒延迟、goroutine 堆栈切换开销，或者误把 <code>select</code> 当作状态机驱动器来用。</p><p>记住：<code>select</code> 是并发同步原语，不是流程控制器。它的“不确定”不是缺陷，是设计使然；试图驯服它，通常说明你该重新梳理通信契约了。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
