Go语言channel通信详解与使用方法

无缓冲channel一用就死锁，因为其本质是同步通信：发送操作必须与接收操作同时就绪，若在单个Goroutine中先后执行发送和接收，发送会永久阻塞等待不存在的接收者，导致所有Goroutine休眠而触发死锁。

无缓冲 channel 为什么一用就死锁？

因为无缓冲 channel 是同步通信：ch <- v 必须等到有 goroutine 在另一端执行 <-ch 才能继续，反之亦然。如果 sender 和 receiver 没有“同时就位”，就会互相等待，触发 runtime panic: fatal error: all goroutines are asleep - deadlock!。

• 常见错误：main goroutine 启动一个 goroutine 发送数据，但自己没写接收逻辑，或接收写在发送之后
• 正确做法：要么用 goroutine 包裹接收端（如 go func() { <-ch }()），要么确保 main 中先启动接收再启动发送
• 调试技巧：加 fmt.Println("before send") 和 fmt.Println("after send")，如果后者不打印，基本就是卡在发送上了

带缓冲 channel 的容量设多少才合适？

缓冲大小不是越大越好，它本质是内存 + 行为语义的权衡：设为 0（等价于无缓冲）强调严格同步；设为 N 允许最多 N 次“非阻塞发送”，但接收端一旦滞后，数据就会堆积在内存里。

• 典型场景：make(chan Task, 10) 适合生产者快、消费者慢但可容忍短暂积压的任务队列
• 反例：设成 10000 又不及时消费，可能引发 OOM 或掩盖背压问题
• 经验法则：从 1 或 cap = 生产者并发数 × 平均每轮产出数 起步，上线后根据 len(ch) 监控值调优

关闭 channel 前必须确认哪些条件？

关闭 channel 是单向、不可逆操作，只应由“数据发送方”在确认**不会再有新数据发出**时调用 close(ch)。误关或重复关闭都会 panic。

• 禁止对 nil channel 调用 close（panic: close of nil channel）
• 禁止对已关闭 channel 再次 close（panic: close of closed channel）
• 接收端不能靠 close 判断“所有数据收完”——必须配合 for range ch 或 v, ok := <-ch 检查 ok == false
• 多个生产者时，不能由任意一个 producer 关闭 channel；需用 sync.WaitGroup 等待全部 producer 结束后，由主 goroutine 统一关闭

如何安全地从多个 channel 中取数据？

直接写 <-ch1 或 <-ch2 是阻塞且单点的，真正需要的是“谁就绪读谁”，这时必须用 select。

• select 会随机选择一个就绪的 case 执行，没有优先级；若多个就绪，结果不确定
• 加 default 可实现非阻塞尝试，但要注意它会立即执行，不等任何 channel 就绪
• 超时控制必须配 time.After，例如：case <-time.After(3 * time.Second): fmt.Println("timeout")
• 切忌在 select 外层套无限 for 循环却不 break —— 容易忽略 channel 已关闭，导致空转消耗 CPU

channel 不是队列 API，也不是线程安全的共享变量替代品；它的核心价值在于通过阻塞行为强制你显式建模“协作时序”。哪怕只是临时传一个 int，也要想清楚：谁发、谁收、谁关、超时怎么处理——漏掉任一环，程序就停在那儿了。