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