channel死锁主因是该关未关或不该关却关：前者致for range无限阻塞，后者引发send on closed channel panic；应由明确不再发送数据的发送方关闭，且仅关一次。
Go里channel死锁最常发生在「该关没关」或「不该关却关了」——前者让for range无限等待，后者导致panic: send on closed channel。核心就一条：**发送方关，接收方不关；关一次，不重复关**。
谁该调用 close()？为什么只能是发送方
接收方无法预知发送是否真正结束，强行关闭会破坏其他 goroutine 的发送逻辑。一旦有 goroutine 向已关闭的 channel 发送数据，运行时立刻 panic。
- 正确做法：由明确知道“不会再发任何数据”的 goroutine 调用
close(ch)，通常是启动发送逻辑的那个协程（或其封装函数） - 错误模式：
go func() { —— 接收方关 channel，后续其他发送者会 panic - 边界情况：多个发送者时，不能随便关；必须用
sync.WaitGroup或context协调全部发送完成后再统一关闭
for range 为什么会卡住？怎样让它自动退出
for v := range ch 本质是持续接收，直到 ch 关闭且缓冲/队列中所有值被取完。如果没人关 channel，它就永远阻塞在最后一次接收上。
- 常见陷阱：只起一个 goroutine 发数据，发完就 return，但忘了
close(ch) - 安全写法示例：
go func() { defer close(ch) // 确保无论从哪条路径退出都关闭 Walk(tree, ch) }() - 注意：
defer close(ch)在匿名函数里才有效；若放在普通函数中，可能在发送未完成时就提前触发
带缓冲 channel 能避免死锁吗？哪些场景仍需 close()
带缓冲能缓解「同步阻塞」，但不能替代关闭逻辑。只要接收方依赖 for range 或需要感知流结束，就必须关 channel。
- 缓冲作用：让发送者不立即阻塞（例如
ch := make(chan int, 10)可缓存 10 个值） - 仍需关闭的场景：
for range循环、select中配合default做非阻塞尝试、或下游需要区分「无数据」和「流已结束」 - 反例：
ch := make(chan int, 1)，只发一个值后不关，接收方用for range仍会死锁
调试死锁时，第一眼该看什么
报错信息 fatal error: all goroutines are asleep - deadlock! 出现后，直接定位最后几行 goroutine 状态，重点查：
- 哪个 goroutine 卡在
或 <code>ch 上 - 对应 channel 是无缓冲还是满缓冲
- 所有向该 channel 发送的 goroutine 是否已退出，且未调用
close() - 有没有 goroutine 在等另一个 goroutine 关 channel，而后者又在等它 —— 典型循环依赖
真正难处理的不是单点关闭遗漏，而是多发送者协作时的关闭时机判断。这时候 sync.WaitGroup 加 close() 必须套在同一 goroutine 内，少一层封装就容易漏掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
