Go Channel死锁是逻辑错误而非运行时异常，因所有goroutine互相等待导致程序卡死；无缓冲通道在main中发送而未接收时会永久阻塞，引发最常见死锁。
Go Channel死锁不是运行时可捕获的异常，而是逻辑错误——程序卡住时，所有 goroutine 都在等对方，谁也不动。必须从设计和执行顺序上解决，不能靠 recover。
无缓冲通道发送阻塞在 main goroutine
这是最常见死锁：你在 main 里直接调用函数往 make(chan int) 发数据，但接收语句还没执行到。发送操作会永久阻塞，main 卡死，整个程序就停了。
- 典型错误写法：
c := make(chan int); c —— 第二行永远等不到接收者 - 正确做法是把发送放进独立 goroutine：
go func() { c ，让 <code>main可以继续走到接收侧 - 切记：无缓冲通道的
和 <code> 必须由两个不同 goroutine 同时准备就绪，不能串行写在同一个 goroutine 里
for range 无限等待未关闭的通道
当你用 for v := range ch 接收数据，但没人关 ch，循环就永远不会退出。Go 不会自动判断“发完了”，它只认 close(ch) 这个信号。
- 常见场景：树遍历、文件逐行读取、worker 池结果收集 —— 数据发完后必须显式
close(ch) - 关闭时机很关键：只能由发送方关闭，且只能关一次；接收方关会 panic
- 推荐模式：在 goroutine 里发完所有数据后
defer close(ch)，确保无论是否提前 return 都能关掉
零值通道（nil channel）导致永久阻塞
声明但没初始化的通道变量是 nil，对它做任何通信操作（、<code>、<code>close）都会让 goroutine 永久休眠。
立即学习“go语言免费学习笔记（深入）”；
- 典型坑点：
chs := make([]chan int, 3)→chs[0]是nil，chs[0] 就死锁 - 修复方式：循环初始化每个元素：
for i := range chs { chs[i] = make(chan int) } - 调试技巧：打印
fmt.Printf("%v", ch)，如果输出<nil></nil>就是零值通道
缓冲通道容量超限后阻塞
make(chan int, 3) 只能存 3 个值；第 4 次 c 会阻塞，直到有人消费——但如果消费者还没启动或已退出，就卡住了。
- 缓冲不是万能解药：它只是把死锁从“立刻发生”延后到“填满时发生”
- 不要盲目加大缓冲量来掩盖逻辑问题，比如本该并发处理却用大缓冲假装异步
- 更安全的做法：配合
select+default或timeout，避免无限等待：select { case c
真正容易被忽略的是关闭通道的时机和责任归属——不是“谁创建谁关闭”，而是“谁负责发送完谁关闭”。一旦多个 goroutine 都可能往同一通道发数据，就得用 sync.WaitGroup 或 context 协调关闭动作，否则还是会在某条路径上漏掉 close。
