Go 中 channel 的 FIFO 行为是严格保证的：hchan 的 recvq、sendq 队列与锁保护的环形缓冲区共同确保发送与接收顺序完全一致，无论缓冲与否、并发度高低。
channel 缓冲区的 FIFO 行为是严格保证的
Go 运行时对 chan 的实现强制维护 FIFO 顺序，无论有无缓冲、容量多大、并发读写 goroutine 多少，发送顺序和接收顺序完全一致。这不是“大概率”或“通常”，而是由 hchan 结构体中 recvq 和 sendq 两个等待队列 + 锁保护的环形缓冲数组共同保障的底层契约。
你不需要额外同步或排序，只要用标准 操作，数据就按发送顺序抵达接收端。例如：
ch := make(chan int, 3)
go func() { ch <- 1; ch <- 2; ch <- 3 }()
for i := 0; i < 3; i++ {
fmt.Println(<-ch) // 总是输出 1、2、3，不会乱序
}缓冲区满/空时 FIFO 不会退化
当缓冲区已满，后续发送操作会阻塞并入队 sendq；当缓冲区为空，接收操作会阻塞并入队 recvq。这两个队列本身也是 FIFO，且 runtime 在唤醒 goroutine 时严格按入队顺序调度。
- 多个发送者同时尝试写满缓冲区，它们的阻塞顺序 = 调度器看到的抢占顺序 = 最终唤醒顺序
- 多个接收者同时等待，第一个被唤醒的一定是最早调用
的那个 - 即使混合了直接传递（无缓冲）和缓冲区拷贝（有缓冲），FIFO 仍贯穿全程：发送者 A → B → C，接收者拿到的永远是 A、B、C
别把“goroutine 调度不确定性”误认为 FIFO 失效
FIFO 稳定性只约束 channel 内部的数据流动顺序，不约束 goroutine 启动/执行时间。下面这段代码输出可能不是 1~6，但 channel 本身的收发顺序依然牢靠：
ch := make(chan int, 2)
go func() { ch <- 1; ch <- 2 }() // goroutine A
go func() { ch <- 3; ch <- 4 }() // goroutine B
go func() { ch <- 5; ch <- 6 }() // goroutine C
// ← 这里 A/B/C 的启动时机、执行快慢不可控真正关键的是：一旦某个值进入 channel（无论是进缓冲区还是直传），它在 channel 队列里的位置就固定了。容易踩的坑是把“谁先调用 ch ”和“谁先被调度执行”混淆——前者决定 FIFO 位置，后者只是影响“何时到达”。
关闭 channel 后的接收仍遵守 FIFO
关闭 ch 后，所有已入缓冲区的数据仍按原顺序被取出；所有阻塞在 recvq 中的接收者也按 FIFO 顺序被唤醒并收到零值（或带 ok=false 的零值）。
注意这个细节：
- 关闭前已入缓冲区的 3 个值：1、2、3 → 接收顺序必为 1→2→3
- 关闭时有 2 个 goroutine 在
recvq等待 → 先入队的那个先被唤醒，返回0, false - 向已关闭的 channel 发送会 panic，但这个 panic 不影响之前已排队的 FIFO 逻辑
最易被忽略的是：FIFO 是 channel 的语义契约，不是优化手段；哪怕你只用一个 goroutine 单线程收发，它依然存在——它刻在 runtime 的 hchan 实现里，关不掉，绕不过。
