死锁在 go 并发中由 channel 操作顺序、goroutine 生命周期和同步逻辑错误共同导致；只要发送与接收无法在多个 goroutine 间形成可完成配对，select 或阻塞操作即引发死锁。
死锁在 Go 并发中通常不是“随机发生”，而是由 channel 操作顺序、goroutine 生命周期和同步逻辑错误共同导致的——只要 channel 的发送和接收不在两个（或多个） goroutine 间形成可完成的配对，select 或 就会永久阻塞。
channel 发送与接收未配对时必然死锁
最常见死锁场景：在一个 goroutine 中向无缓冲 channel 发送，但没有其他 goroutine 同时接收；或接收方已退出，发送方仍在尝试写入。
- 无缓冲 channel
c := make(chan int)：发送操作c 会一直等待接收者就绪，若接收逻辑缺失或被跳过，立即死锁 - 有缓冲 channel
c := make(chan int, 1)：最多允许一次未接收的发送；第二次c 会阻塞，若无人消费则仍死锁 - 在
main函数中直接写c 且无并发接收者，程序启动即 panic: <code>fatal error: all goroutines are asleep - deadlock!
使用 select 时漏掉 default 或 timeout 导致隐式阻塞
select 本身不保证非阻塞；如果没有可用 channel 操作，又没写 default，就会卡住——尤其在循环中反复 select 却忽略退出条件时，极易演变成死锁。
- 错误写法：
select { case v := —— 若 <code>ch关闭或长期无数据，该 goroutine 永久挂起 - 安全写法应包含超时或默认分支：
select { case v := - 如果用
select等待多个 channel，但其中某个 channel 永远不会就绪（比如它所属的 goroutine 已 panic 退出），其余分支也救不了整体逻辑
goroutine 泄漏 + channel 阻塞 = 隐性死锁
表面上没报 deadlock panic，但程序不再响应、CPU 归零、内存缓慢上涨——这是 goroutine 在 channel 上永久等待，且无外部信号终止它。
立即学习“go语言免费学习笔记（深入）”；
- 典型模式：启动一个 goroutine 处理 request，向 response channel 发送结果，但调用方未读取、也未关闭 channel，该 goroutine 就卡在
respChan - 解决关键不是加
defer close(ch)，而是确保发送前检查接收方是否活跃（例如用带超时的select）或改用带取消机制的 context - 用
go tool trace或runtime.NumGoroutine()定期观测，能快速识别“只增不减”的 goroutine
关闭已关闭的 channel 或向已关闭 channel 发送会 panic，但不是死锁
这个错误常被误认为死锁，实际是运行时 panic：panic: send on closed channel 或 panic: close of closed channel。它和死锁性质不同，但往往出现在同类调试场景中。
- 关闭 channel 前务必确认：没有 goroutine 正在（或将要）向其发送数据
- 接收端可通过
v, ok := 判断 channel 是否已关闭，<code>ok == false表示已关且无剩余数据 - 不要依赖
close(ch)来“唤醒”阻塞的发送方——它不会解除阻塞，只会让下一次发送 panic
真正难排查的是那些依赖执行时序的 channel 交互：比如 A 向 B 发消息后等 B 回复，B 却在收到消息后先等 C 的响应……这类环状等待需要靠明确的超时、context 取消和有限重试来打破，而不是靠“多加几个 goroutine”来掩盖。
