Go的select语句在多个case就绪时确实会伪随机选择一个执行，但“就绪”是前提——若某些case因通道未被消费而持续阻塞，则实际仅剩一个可选分支，自然每次都进入该分支。
go的select语句在多个case就绪时确实会伪随机选择一个执行，但“就绪”是前提——若某些case因通道未被消费而持续阻塞，则实际仅剩一个可选分支，自然每次都进入该分支。
在Go并发编程中，select语句常被误解为“总是公平随机”，但其行为严格遵循两个核心原则：阻塞等待与就绪优先。只有当多个case同时处于就绪状态（ready） 时，select才会从其中伪随机（uniformly at random） 选取一个执行；若仅有一个case就绪，无论运行多少次，它都会被选中——这并非bug，而是确定性调度的必然结果。
以提问中的多发送case为例：
select {
case c <- 1: x, y = y, x+y
case c <- 2: x, y = y, x+y
// ... 其他c <- N
case <-quit: fmt.Println("quit"); return
}表面看有7个case，但前6个均为向缓冲区满或无人接收的channel c 发送数据，属于阻塞操作。只要c未被其他goroutine消费（即没有
真正的随机性只在多个通道同步就绪时显现。如下示例清晰展示了这一点：
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"fmt"
"time"
)
func main() {
c := make(chan int, 1) // 缓冲通道，避免立即阻塞
quit := make(chan struct{})
// 启动goroutine在5秒后关闭quit
go func() {
time.Sleep(5 * time.Second)
quit <- struct{}{}
}()
// 启动goroutine每秒向c发送一个值
go func() {
for i := 0; ; i++ {
time.Sleep(1 * time.Second)
c <- i
}
}()
// 主goroutine：select监听c和quit
for {
select {
case val := <-c:
fmt.Printf("Received from c: %d\n", val)
case <-quit:
fmt.Println("quit")
return
}
}
}注意：此处c设为buffered channel (cap=1)，且发送端有time.Sleep控制节奏，确保主goroutine每次select时c大概率有数据可读；同时quit在第5秒才就绪。在前4秒内，真正随机选择——你可能看到Received from c: 4先于quit，也可能quit立即触发并退出，多次运行结果不一致，这正是Go运行时runtime.selectgo算法的体现。
⚠️ 关键注意事项：
- 就绪性取决于通道状态：send操作就绪需通道有空闲缓冲或存在等待接收者；receive操作就绪需通道非空或存在等待发送者。
- 无默认分支时select会阻塞：若所有case均未就绪，goroutine挂起，直到至少一个就绪。
- 随机性是伪随机且不可预测：Go不保证跨版本/平台的随机序列一致，不应依赖特定顺序做逻辑判断。
- 避免“假随机”陷阱：如原问题中因通道未消费导致发送case永远不就绪，本质是程序逻辑缺陷，而非select机制失效。
总结而言，select的随机性是就绪集合上的均匀采样，而非对全部case的盲目轮询。理解通道的就绪条件（buffer状态、goroutine协作关系），才能正确设计并发流程，让select真正发挥其非阻塞、多路复用与公平调度的价值。
