本文揭示了 go 程序中两个 goroutine 能近乎完美交替打印 "ping"/"pong" 的本质原因：无缓冲通道（unbuffered channel）的同步语义强制协程严格配对阻塞与唤醒，形成确定性的协作调度模式。
在您提供的示例中，table := make(chan *Ball) 创建的是一个无缓冲通道（unbuffered channel），这是理解整个行为的关键。无缓冲通道不具备内部存储空间，其发送（ch 同步发生——即发送方会一直阻塞，直到有另一个 goroutine 正在等待接收；反之，接收方也会阻塞，直到有发送方准备就绪。
因此，player("ping", table) 和 player("pong", table) 并非“并发竞争”，而是被通道天然建模为严格交替的协作状态机：
- 主 goroutine 启动两个 player 后，向 table 发送初始球 table
- 此时任意一个 player（如 ping）成功接收该球，执行 ball.hits++、打印 "ping 1"，再尝试发送回球：table
- 但该发送操作无法立即完成——因为此时 pong 还未开始接收（它刚被调度或仍在初始化）。于是 ping 协程主动挂起并让出执行权；
- 调度器随即唤醒 pong：它从 table 成功接收球，打印 "pong 1"，再执行 table
- 同样，该发送又需等待 ping 再次就绪接收……如此循环往复。
这种“发送即阻塞、接收即唤醒”的机制，使两个 goroutine 实质上构成一个隐式的双相栅栏（two-phase barrier），天然规避了竞态与失序。这也是为何统计结果总是 #ping ≈ #pong ± 1：最后一次发送可能因 time.Sleep(1s) 结束而被主 goroutine 的
✅ 正确理解：这不是“调度器保证公平”，也不是“时间片轮转”，而是通道同步语义强加的协作协议。 ⚠️ 注意事项： 若改为带缓冲通道（如 make(chan *Ball, 1)），则初始发送不会阻塞，可能导致 ping 连续执行多次，破坏交替； 移除 time.Sleep 并用更健壮的退出机制（如 done channel 或 sync.WaitGroup）可避免截断风险； fmt.Println 本身非原子操作，但在本例中因通道同步已确保调用顺序，故输出行序仍高度可靠（实际生产中高并发日志仍建议加锁或使用结构化日志库）。
简言之，Go 的无缓冲通道不是“通信管道”，而是协程间的同步原语——它让并发逻辑回归到清晰、可推理的协作模型，这正是 Go “不要通过共享内存来通信，而应通过通信来共享内存” 设计哲学的生动体现。
