go程序出现“fatal error: all goroutines are asleep - deadlock!”即所有goroutine全部阻塞且无法唤醒，根本原因是channel收发不配对：无缓冲channel发送前必须有接收方就位，for range未close会永久等待，单goroutine先发后收必然死锁。
Go程序一旦出现 fatal error: all goroutines are asleep - deadlock!，基本可以断定是Channel通信逻辑没对上——不是发送没人收，就是接收没人发，或者关闭时机不对。
为什么ch 会直接panic？
无缓冲Channel要求发送和接收**必须同时就绪**。主goroutine执行 ch 时，没有其他goroutine在等这个channel，它就卡住不动；而整个程序只剩这一个goroutine，运行时立刻判定“所有goroutine都在睡觉”，直接崩溃。
- 这是最典型的死锁触发点：单goroutine向无缓冲channel写入
- 哪怕只多一行
go func() { ，就不会panic（但可能有其他问题） - 缓冲channel如
make(chan int, 1)能暂存一个值，ch 不阻塞，但 <code>ch 仍会卡住
for range ch卡住不退出？检查是否close了channel
接收方用 for range ch 等数据，但发送方没调用 close(ch)，循环就永远等下去。这不是“错误”，而是逻辑遗漏——range只在channel被关闭且缓冲区清空后才退出。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 关闭必须由**发送方**完成，且只能关一次；多个goroutine并发关会panic
- 常见陷阱：goroutine提前return，忘了
defer close(ch) - 如果发送方用
select+ctx.Done()退出，务必在return前close
pprof看堆栈：哪些goroutine在等channel？
死锁不一定立刻报错（比如还有后台goroutine在跑），这时要靠 pprof 抓现场。启动时加 net/http/pprof，访问 /debug/pprof/goroutine?debug=2 就能看到所有goroutine的阻塞点。
- 重点关注状态为
chan receive或chan send的goroutine - 堆栈里出现
runtime.gopark+chanrecv/chansend，基本就是卡在channel上了 - 对比发送和接收的代码行号，看是不是一方永远没启动，或顺序反了
select default分支吞数据？别让它掩盖阻塞
用 select { case ch 看似防阻塞，但default分支一执行，数据就丢了——你没解决“谁来收”的问题，只是假装处理了。
- default适合做“非关键数据丢弃”，比如日志、监控采样
- 业务核心数据流不能依赖default兜底，否则接收端永远等不到
- 真要防卡死，用
select { case ch
死锁真正难缠的地方不在报错那一瞬，而在它不报错——goroutine静默泄漏、channel半开着、数据悄悄丢掉。盯紧关闭动作、核对收发配对、别让default当遮羞布，比事后抓堆栈更省力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
