遇到deadlock时，检查Channel缓冲区配置。分析堆栈定位阻塞于`chansend`或`chanrecv`的行。无缓冲通道需同步握手，带缓冲通道满或空时阻塞。`select`无`default`且缓冲满/空易致主协程死锁。
看到 `fatal error: all goroutines are asleep - deadlock!` 别慌，也别急着去翻业务逻辑——先停手，检查 Channel 缓冲区配置。这不是程序卡顿，是 Go 运行时确认所有协程都陷入“等不到对方就绪”的状态后主动终止。需要立刻分析 panic 日志中的 goroutine 堆栈，定位卡在 `chan send` 或 `chan recv` 的具体行，区分无缓冲通道的同步阻塞与带缓冲通道因满/空导致的延时死锁。
先说个核心判断：缓冲区配置不当——比如该用带缓冲却用了无缓冲、缓冲大小与业务节奏不匹配——是最常见的死锁诱因之一。关键不是猜逻辑，而是看 panic 日志末尾的 goroutine 堆栈，尤其是哪一行在阻塞、哪些 goroutine 全卡在 `chan send` 或 `chan recv`。
* 无缓冲 Channel（`make(chan int)`）本质是同步握手：发送方必须等到接收方 ready 才能继续；漏掉任意一端，就是死锁温床。
* 带缓冲 Channel（`make(chan int, 10)`）只是延缓死锁：当 `len(ch) == cap(ch)` 时，再 send 就阻塞；当 `len(ch) == 0` 且未关闭时，再 recv 就阻塞。
* 缓冲大小 ≠ 并发数：设成 100 不代表能扛住 100 个并发写入，如果消费者处理慢、积压满，后续写入仍会挂起。
### `select` 没 `default` + 缓冲区满/空 = 主 goroutine 直接死锁
这是高发场景：你用 `select` 等待一个带缓冲 Channel，但没加 `default`，又没配超时，一旦 Channel 满（send）或空（recv），当前 goroutine 就挂起。如果这是 main goroutine，且没有其他活跃协程，立刻触发死锁。
* 错误写法：`select { case ch <- v: ... }` —— Channel 满时永久阻塞。
* 临时缓解：`select { case ch <- v: default: ... }`，但注意 `default` 是非阻塞轮询，高频下需加 `runtime.Gosched()` 或小延时，否则吃 CPU。
* 真正解法：结合 `time.After` 做超时控制，或用 `context.WithTimeout` 统一管理生命周期。
### 用 `go tool trace` 定位“谁在等谁”比看日志更直接
`pprof` 的 goroutine profile 只能看到栈帧，而 `go tool trace` 能还原状态变迁时间线，一眼看出哪个 goroutine 长期处于 `chan send` 或 `chan recv`，且无对应唤醒者。
* **启用方式**：启动前加 `import _ "net/http/pprof"` 和 `go http.ListenAndServe("localhost:6060", nil)`。
* **采集 trace**：`curl "http://localhost:6060/debug/trace?seconds=5" -o trace.out`。
* **分析重点**：打开 Web UI → “Goroutine” 标签页 → 筛选状态为 `chan send` → 查看该 goroutine 是否长时间停留、有无 sender/receiver 成对出现。
* **兼容提示**：Go 1.20+ 对 Channel 阻塞点追踪更细，旧版本建议升级。
### `close()` 时机和主体错乱会让缓冲区配置失效
即使使用了带缓冲 Channel，如果 `close()` 由错误 goroutine 执行、或执行太早/太晚，消费者仍可能永远等不到 EOF，导致 `for v := range ch` 卡死，最终演变为死锁。
* **常见错误**：生产者 goroutine 发完数据就 `close(ch)`，但消费者还没启动；或多个 goroutine 争抢 `close()`，造成 `panic: close of closed channel`。
* **安全模式**：只由唯一 producer goroutine `defer close(ch)`，consumer 用 `v, ok := <-ch` 或 `for range` 主动判断关闭。
* **缓冲区再大也救不了**：如果没人关 Channel，receiver 即使读完所有缓冲数据，也会继续等待新数据，直到所有 goroutine 都阻塞。
缓冲区配置不是调参游戏，它和谁发、谁收、谁关、何时退出强耦合。最容易被忽略的是：**无缓冲 Channel 的长度永远是 0，`len(ch)` 完全不能用来判断可写性；而带缓冲 Channel 的满/空状态，只有在明确知道当前并发节奏和消费能力的前提下，才有意义。**
