Channel的FIFO顺序由运行时严格保证：无论缓冲区大小如何，数据入队与出队均严格遵循先进先出；缓冲区仅影响阻塞时机，不改变队列行为，recvq和sendq调度按链表顺序出队，是runtime硬保证。
channel 的 fifo 顺序在单个 channel 上是稳定且可依赖的，但仅限于“发送顺序”与“接收顺序”的一致 —— 不代表多 goroutine 并发写入时你能控制谁先发、谁后发。
为什么「缓冲区大小」不影响 FIFO 稳定性
缓冲区只是改变了阻塞时机，不改写队列行为。无论 make(chan int, 0) 还是 make(chan int, 100)，只要数据进了 channel，它就排队；只要接收发生，就从队头取。Go 运行时对 recvq 和 sendq 的调度严格按链表顺序出队，这是 runtime 层硬保证的。
常见错误现象：以为给大缓冲区就能“让快的 goroutine 多塞几条，慢的追不上”，结果发现接收端还是按发送进队列的次序拿值 —— 对，这恰恰说明 FIFO 生效了；错在误判了“谁先发送”的时机。
- 无缓冲 channel：发送必须等到接收者就绪，所以发送顺序 ≈ 调度器实际执行顺序
- 有缓冲 channel：发送方可能一口气塞满缓冲区，此时“发送完成”不等于“已入队完成”，但 runtime 内部仍逐个拷贝、逐个入队，顺序不变
- 性能影响：缓冲区越大，单次
ch 越快（避免阻塞），但不会提升“多生产者并发写入时的逻辑顺序可控性”
真实测试中容易被忽略的并发干扰点
你写一个循环启动 5 个 goroutine 往同一个 channel 发 1~5，然后主协程 range 接收 —— 看起来输出是 1 2 3 4 5，就以为“FIFO 成立”。其实这只是巧合：goroutine 启动和调度存在微小时间差，而你的发送逻辑又极轻量，导致它们几乎按启动顺序依次执行。
真正要验证稳定性，得制造竞争：
- 用
time.Sleep(time.Microsecond * 100)在每个 goroutine 发送前加随机抖动 - 把发送值改成带时间戳的结构体，比如
struct{ n int; ts time.Time }，接收后比对ts和打印顺序 - 关闭 channel 前不加同步（比如忘了
sync.WaitGroup），导致部分 goroutine 还没发完就被主协程退出，看起来“漏数”或“乱序”
你会发现：只要所有发送都成功进入 channel，接收端拿到的 n 值永远是按入队顺序排列的 —— 即使 ts 显示第 3 个 goroutine 实际最早开始执行。
select 多 case 场景下别误判 FIFO
select 本身不保序，这是最常踩的坑。哪怕你往两个不同 channel（ch1, ch2）里按 1→2→3 和 4→5→6 的顺序发，再用 select { case 接收，结果完全不可预测。
原因在于：select 是从所有就绪的 case 中伪随机选一个执行，跟“哪个先发”“哪个缓冲大”都没关系。它只看“此刻哪些 channel 有数据可读”，不维护跨 channel 的时间线。
- 如果你需要跨 channel 的有序消费，得自己加序号字段，统一走一个 channel，或者用
sync.Mutex+ 切片暂存 + 定期排序 - 缓冲区大小对
select行为零影响 ——make(chan int, 1)和make(chan int, 100)在select里表现完全一样 - 不要用
select+ default 来“轮询多个 channel 并假装按顺序处理”，default 会破坏任何潜在的时序假设
用 benchmark 验证 FIFO 性能开销是否随缓冲区变化
FIFO 本身无额外开销，但缓冲区大小会影响内存分配和 GC 压力。你可以用 go test -bench=. 对比：
func BenchmarkFIFOSingleProducer(b *testing.B) {
ch := make(chan int, b.N/10) // 控制缓冲区占总操作比例
for i := 0; i 你会发现：
- 缓冲区为 0 时，
BenchmarkFIFOSingleProducer-8可能因 goroutine 频繁阻塞/唤醒而吞吐略低 - 缓冲区为 100 时，单次发送延迟下降明显，但总耗时未必线性改善（受调度器和内存拷贝影响）
- 所有情况下，接收端拿到的数值序列始终是 0,1,2,...,b.N-1 —— 这才是 FIFO 稳定性的直接证据
真正复杂的地方从来不是“channel 是否 FIFO”，而是你能否清晰区分：哪些顺序由 channel 保证，哪些顺序必须由你用额外机制（序号、锁、单 writer）来保证。
