本文深入解析 Go 语言中无缓冲通道的同步阻塞特性，说明为何在 runner 函数中先向 b 发送再向 c 发送会导致最后一个 goroutine 永久阻塞，进而使部分数据无法送达 c 通道。
本文深入解析 go 语言中无缓冲通道的同步阻塞特性，说明为何在 `runner` 函数中先向 `b` 发送再向 `c` 发送会导致最后一个 goroutine 永久阻塞，进而使部分数据无法送达 `c` 通道。
在 Go 并发模型中，通道（channel）不仅是数据传递的管道，更是 goroutine 间同步的基石。其行为高度依赖于缓冲容量和发送/接收的配对时机。你提供的代码中，核心问题源于对无缓冲通道 bucket := make(chan []int) 的误用：
bucket := make(chan []int) // 容量为 0 —— 无缓冲通道
无缓冲通道要求 发送操作必须与接收操作严格配对：每次 b 都会立即阻塞，直到有另一个 goroutine 正在执行 。这正是死锁的根源。
我们来追踪执行流程：
- 主 goroutine 向
bucket发送初始切片[]int{1..20}； - 四个
runnergoroutine 同时启动，但只有第一个能立即从bucket接收（其余三个因无缓冲而阻塞在）； - 第一个
runner处理完前 5 个非零元素后，执行b —— 此时它试图将修改后的切片“回传”给bucket； - 但此时 没有其他 goroutine 在等待接收
bucket（因为其余三个仍卡在初始，尚未进入处理逻辑），因此该发送操作永久阻塞； - 由于 Go 中 goroutine 是顺序执行的，
b 不返回，后续的c 就永远不会执行 → 该 runner 的结果永远无法到达c通道； - 更严重的是：剩余三个
runner永远无法被唤醒，因为bucket上再无新数据可消费（第一个卡死，后续无人发送），整个流水线彻底停滞。
✅ 正确做法是：确保通道操作不会引入未配对的阻塞点。有两种主流修复方案：
方案一：为 bucket 添加缓冲（推荐用于此场景）
让 bucket 能暂存多个待处理块，避免 goroutine 过早阻塞：
bucket := make(chan []int, 4) // 缓冲区大小 ≥ runner 数量
方案二：调整发送顺序 + 显式控制流程（更健壮）
优先将结果发往 c（由 printer 消费），再将剩余数据放回 bucket，并配合 sync.WaitGroup 或关闭机制终结：
func runner(idx int, c chan []int, b chan []int, wg *sync.WaitGroup) {
defer wg.Done()
bucket := 0 {
b <p>⚠️ 关键注意事项：</p>
- 无缓冲通道 = 同步信令，适用于严格配对的“请求-响应”或“握手”场景；
- 多生产者/多消费者模型中，务必保证发送与接收的拓扑平衡，避免“单点阻塞导致全链路瘫痪”；
- 使用
select+default可实现非阻塞发送，但需谨慎设计 fallback 逻辑； - 始终通过
go tool trace或pprof检查 goroutine 状态，及时发现阻塞 goroutine。
总结：Go 通道不是“队列”，而是“协程协作契约”。理解其阻塞语义，比掌握语法更重要——一次错误的发送顺序，可能让整个并发流水线静默失效。
