Go中典型死锁是channel操作未配对：向无缓冲channel发送时无人接收，或接收时无人发送，运行时panic提示“all goroutines are asleep - deadlock!”。
channel 操作未配对导致的死锁
Go 中最典型的死锁，就是
goroutine
在向无缓冲 channel 发送数据时阻塞，且没有其他 goroutine 从该 channel 接收；或从 channel 接收时阻塞，但无人发送。编译器无法静态检测这类逻辑死锁，运行时 panic 提示为
fatal error: all goroutines are asleep - deadlock!
。
常见诱因：
在主 goroutine 中直接
ch ，而接收逻辑被错误地放在另一个未启动的 goroutine 里
用
select
读 channel 时漏写
default
，且 channel 暂时空
关闭 channel 后仍尝试发送（会 panic），但更隐蔽的是：关闭后继续接收——这本身不 panic，但若接收方没感知关闭，可能卡在循环中等不到新数据
func main() {
ch := make(chan int)
ch <- 42 // 死锁：主 goroutine 卡在这里，无其他 goroutine 接收
}
sync.Mutex 或 sync.RWMutex 重复加锁
sync.Mutex
不可重入。同一个 goroutine 连续两次调用
mu.Lock()
会导致永久阻塞——它不会报错，也不会超时，只会卡死。
容易踩坑的场景：
立即学习
“
go语言免费学习笔记（深入）
”；
方法内部调用自身（递归）且都持锁
组合结构体嵌套调用不同方法，各自独立加锁，但实际共享同一把锁
defer mu.Unlock() 写在函数开头而非临界区结尾，导致解锁时机错误
func (s *Service) DoWork() {
s.mu.Lock()
defer s.mu.Unlock() // 错：这里 defer 的是第一次 Lock 对应的 Unlock
s.mu.Lock() // 死锁：第二次 Lock 永远等不到释放
// ...
}
WaitGroup 使用不当引发的等待僵局
sync.WaitGroup
本身不直接导致死锁，但误用会让主 goroutine 永远等待不存在的完成信号。
go语言参考手册 中文CHM版
Go 是一个开源的编程语言，它能让构造简单、可靠且高效的软件变得容易。本文给大家带来Go参考手册，需要的可以来下载！ Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发，后来还加入了Ian Lance Taylor, Russ Cox等人，并最终于2009年11月开源，在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的，并且拥有一个活跃的社区。 Go 语言特色 简洁、快速、安全 并行、有趣、开源 内存管理、v数组安全、编译
下载
典型错误：
wg.Add(1)
在 goroutine 启动之后才调用（竞态，Add 可能被跳过）
goroutine 中忘记调用
wg.Done()
，或因 panic 未执行到（应配合 defer）
在循环中反复创建新 WaitGroup 实例，却对旧实例调用
Wait()
func main() {
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
go func() {
// wg.Add(1) 漏了！下面 wg.Wait() 将立即返回，或更糟：如果 wg 已 Add 过但没 Done，就永远等
time.Sleep(time.Second)
// wg.Done() 也漏了
}()
}
wg.Wait() // 可能立刻返回（wg 计数为 0），也可能死锁（若某处误 Add 但没 Done）
}
select + timer 组合中的隐式阻塞
看似安全的
select
如果只包含带
time.After
的 case，且没有
default
或其它可就绪 channel，仍可能因 timer 未触发而长期挂起——这不是死锁（runtime 能识别），但行为等效于“逻辑卡住”。
真正危险的是：timer 和 channel 共存时，误认为 “只要 timer 到了就一定走 default”，其实
select
是随机选择多个就绪 case 的，若 channel 恰好在此刻就绪，timer 就被跳过了。
依赖
time.After
做超时，但未用
case + case 配对，而是单独启动 goroutine 写 channel，主逻辑只等 timer——这不算死锁，但业务会丢数据
在循环中反复创建新 timer，却不 stop，造成 goroutine 泄漏+资源耗尽，间接诱发调度延迟甚至疑似死锁
select {
case msg := <-dataCh:
handle(msg)
case <-time.After(5 * time.Second):
log.Println("timeout") // 正确用法：与 channel case 并列
}
死锁往往不是单点错误，而是多个同步原语在时序和所有权上的错配。调试时别只盯 panic 信息，先确认所有 channel 是否有确定的发送/接收端、所有锁是否成对出现、所有 WaitGroup 的 Add/Done 是否严格对应——尤其注意那些“本该执行却没执行”的 defer 或 done。
