本文解析 go 并发中 goroutine 向同一 channel 发送数据时的接收顺序问题，阐明其非随机、非确定、但实际运行中常表现稳定的本质原因，并提供可验证的代码示例与工程实践建议。
本文解析 go 并发中 goroutine 向同一 channel 发送数据时的接收顺序问题，阐明其非随机、非确定、但实际运行中常表现稳定的本质原因，并提供可验证的代码示例与工程实践建议。
在 Go 并发编程中，一个常见误区是认为：当多个 goroutine 同时向同一个无缓冲 channel 发送数据，且主 goroutine 以固定顺序（如 x, y := <-c, <-c）接收时，接收结果应“随机”交替——比如 50% 概率得到 17 -5，50% 概率得到 -5 17。但实际运行中，该程序
几乎总是输出相同结果（如 -5 17 12 或 17 -5 12），且多次运行顺序不变
。这引发疑惑：goroutine 不是并行执行的吗？调度器难道不随机选？
答案是：
Go 调度器不保证、也不设计为“随机调度”
。它的核心承诺是：
goroutine 将在某个未来时刻被调度执行
，而非“以均匀概率在任意时刻被唤醒”。当前 Go 运行时（截至 Go 1.23）采用
M:N 调度模型（GMP）
，其中新创建的 goroutine 通常被放入
当前 P 的本地运行队列（runqueue）尾部
；而 channel 发送操作在无竞争、无阻塞时极快完成，导致两个 goroutine 往往按启动顺序（即 go sum(...) 的调用先后）快速完成计算并发送——
执行路径高度可复现，非因“固定顺序”，而是因低延迟+无干扰下的自然时序收敛
。
以下代码直观验证这一机制：
典型输出：
可见：
先启动的 goroutine 更可能先完成发送
（因其更早进入就绪队列），接收端按发送完成顺序依次取出——这并非语言规范保证的“顺序保证”，而是当前实现下的
高概率时序现象
。
⚠️ 关键注意事项：
绝不依赖接收顺序
：Go 语言规范明确指出：
多个 goroutine 向同一 channel 发送时，接收端获取值的顺序未定义（unspecified）
。即使当前版本稳定输出，升级 Go 版本、调整 GOMAXPROCS、引入 I/O 或内存竞争都可能改变行为。
需要有序结果？请显式控制
：
✅ 使用带索引的结构体：c <- struct{idx int; val int}{0, sum}，接收后按 idx 排序；
✅ 使用 sync.WaitGroup + 共享切片 + mutex；
✅ 改用带缓冲 channel 并预分配容量，配合 select 超时避免死锁。
select 的随机性 ≠ goroutine 调度随机性
：select 在多个可用 channel 操作间
确实会伪随机选择
（这是语言规范强制要求），但这与“goroutine 何时被调度执行”属于不同抽象层，不可混淆。
总结：你的代码输出稳定，不是因为 Go “固定了顺序”，而是因为简单场景下执行路径高度一致；真正的并发健壮性，永远建立在
显式同步与数据结构设计
之上，而非对调度器行为的隐式假设。
package main
import (
"fmt"
"runtime"
"time"
)
func sum(a []int, c chan int, id string) {
sum := 0
for _, v := range a {
sum += v
}
fmt.Printf("[SEND %s] computed %d\n", id, sum)
c <- sum // 非阻塞发送（无缓冲 channel）
}
func main() {
runtime.GOMAXPROCS(1) // 强制单 P，减少调度干扰
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int)
go sum(a[len(a)/2:], c, "right") // 先启动：[4,0] → sum=4
go sum(a[:len(a)/2], c, "left") // 后启动：[7,2,8] → sum=17
time.Sleep(1 * time.Millisecond) // 确保两个 goroutine 已启动（但未必完成）
x, y := <-c, <-c // 接收
fmt.Printf("Received: x=%d, y=%d → sum=%d\n", x, y, x+y)
}[SEND right] computed 4
[SEND left] computed 17
Received: x=4, y=17 → sum=21