向无缓冲 channel 发送数据时若无接收协程，会永久阻塞并触发死锁 panic；常见原因包括未启动接收 goroutine 或接收逻辑被条件跳过。
channel 操作未配对导致死锁
Go 中最典型的阻塞是向无缓冲 channel 发送数据时，没有协程在另一端接收，send 会永久阻塞当前 goroutine。运行时检测到所有 goroutine 都在等待（包括 main），就会 panic fatal error: all goroutines are asleep - deadlock。
常见于忘记启动接收协程，或接收逻辑被条件跳过：
ch := make(chan int) ch <- 42 // 这里立刻死锁：没人收
- 无缓冲 channel 必须「发送」和「接收」严格配对，且至少一个在运行中
- 用
make(chan int, 1)创建带缓冲 channel 可缓解，但缓冲区满后仍会阻塞 - 调试时加
go func() { fmt.Println(receiving...
); 快速验证是否漏了 receiver
select 默认分支缺失引发无限等待
当 select 中所有 channel 操作都不可达（如全满/全空），又没写 default，goroutine 就会挂起——这不是死锁，但行为上就是卡住不动。
例如从多个 channel 读取，但其中某个始终没数据、也没设超时：
select {
case v := <-ch1:
fmt.Println(v)
case v := <-ch2:
fmt.Println(v)
// 缺少 default 或 timeout，ch1 和 ch2 都没数据时就永远等- 想非阻塞尝试读写，必须加
default:分支（哪怕只写default: continue） - 想限时等待，用
time.After或time.NewTimer接入 select -
select {}是经典空阻塞写法，常用于让 goroutine 永久休眠，但要确认这是有意为之
sync.WaitGroup 使用不当造成 main 提前退出或 hang 住
WaitGroup 本身不阻塞，但误用会导致预期外的阻塞或 panic。最常见的是：Add() 调用晚于 Go 启动，或 Done() 被漏调、多调。
- 必须在
go语句前调用wg.Add(1)，否则新 goroutine 可能已执行完Done()，而 main 已调用wg.Wait()返回 -
Done()被漏调 →Wait()永远不返回；被多调 → panicpanic: sync: negative WaitGroup counter - 不要在循环里反复
var wg sync.WaitGroup：每次重声明会丢掉之前的计数，应定义一次、复用
net/http 服务未设超时引发连接级阻塞
HTTP server 默认不设读写超时，客户端异常断连、慢请求、大文件上传未完成等情况，都会让 goroutine 卡在 conn.Read() 或 conn.Write() 上，堆积大量 idle goroutine。
- 用
http.Server的ReadTimeout、WriteTimeout、IdleTimeout显式控制 - 不要依赖
context.WithTimeout在 handler 内部做超时——它只能中断业务逻辑，无法终止底层 TCP 连接读写 - 长连接场景（如 WebSocket）需额外处理
Ping/Pong心跳，避免因网络闪断导致连接滞留
实际并发阻塞往往不是单点问题，而是 channel 设计、超时策略、资源释放三者耦合的结果。尤其要注意：Go 不会自动回收“卡住”的 goroutine，只要它还在等，就会一直占内存和栈空间。
