Go中无“线程阻塞模块”，阻塞发生在goroutine级别，源于调度器无法唤醒等待状态的G；排查需聚焦goroutine状态和runtime行为，panic日志中的堆栈是唯一可信的第一现场，重点检查main goroutine卡住位置。
Go里没有“线程阻塞模块”这个概念——阻塞发生在 goroutine 级别，根源是调度器无法唤醒处于等待状态的 G，常见于 channel、锁、网络 I/O、定时器等同步原语上。排查必须绕过“模块”思维，直接盯住 goroutine 状态和 runtime 行为。
看 panic 日志里的 goroutine 堆栈
死锁触发时，Go 运行时会立即 panic 并打印所有 goroutine 的当前调用栈。这不是辅助信息，是唯一可信的第一现场。
- 重点检查
maingoroutine 卡在哪一行：比如停在ch 、<code>、<code>mu.Lock()、wg.Wait()或select {} - 观察其他 goroutine 是否全卡在同一类操作：全部停在
chan send说明没人接收；全部停在chan recv说明没人发送；多个卡在(*RWMutex).RLock可能是读锁重入 - 若日志被截断，加环境变量运行：
GODEBUG=schedtrace=1000 go run main.go，每秒输出调度快照，看G数是否长期为 0
用 pprof 抓取阻塞概览
net/http/pprof 的 /debug/pprof/goroutine?debug=2 路径能导出完整 goroutine 列表，比 panic 日志更全，尤其适合非死锁类的长期阻塞（如协程卡在未关闭的 channel 上）。
- 启动时注册：
http.ListenAndServe("localhost:6060", nil)，然后curl http://localhost:6060/debug/pprof/goroutine?debug=2 - 重点关注状态为
chan receive、semacquire（锁）、select、IO wait的 goroutine 数量和堆栈 - 注意区分
runtime.gopark（正常挂起）和runtime.park_m（可能已卡死），后者常伴随无唤醒源
网络 I/O 阻塞必须查超时设置
net.Conn.Read 卡住，99% 是 socket 无数据且没设超时，不是 Go 本身问题。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否漏掉
conn.SetReadDeadline()或conn.SetReadTimeout()，尤其是自定义net.Conn实现 - 对
http.Client，必须组合设置三处超时：DialContext.Timeout（建连）、TLSHandshakeTimeout（握手）、ResponseHeaderTimeout（header 返回），单靠Timeout字段无法覆盖全过程 - 用
tcpdump或Wireshark抓包确认对端是否真发了数据；注意 Linux TCP 栈可能延迟发送 FIN，导致Read等数秒才返回io.EOF
channel 阻塞要分清死锁、永久等待和锁竞争
无缓冲 channel 发送前没接收者、for range 未 close、单 goroutine 先发后收，这三类都会立刻死锁；但有缓冲 channel 满了没人读、或接收方忘了 close()，会导致 goroutine 永久等待，不 panic 却持续占用内存。
- 不要用
len(ch) == cap(ch)判断可写性：无缓冲 channel 的cap(ch)永远是 0，len(ch)永远是 0，该判断无效 - 避免在单个 goroutine 中对同一
sync.RWMutex多次调用RLock()，标准库明确禁止，会破坏内部计数，导致其他 goroutine 永久等待 - 高频写 channel 的场景，
sendq和recvq队列争抢hchan.lock会造成 CPU 上升，此时应考虑拆分 channel 或改用无锁队列（如fastcache类方案）
真正难排查的不是 panic 死锁，而是那些不报错、goroutine 数缓慢上涨、内存持续增长的“慢性阻塞”——它们往往藏在 for range 未 close、协程启动后忘记回收、或 RWMutex 读锁嵌套调用里。这些地方没有明显错误提示，只能靠 pprof 定期采样和代码规范硬约束。
