block profile需显式开启，通过runtime.SetBlockProfileRate(1)和_ "net/http/pprof"注册handler，采集阻塞同步原语的总时长，结合goroutine?debug=2和mutex profile交叉分析阻塞根因。
直接看 block profile 和 mutex profile，配合 goroutine?debug=2 调用栈，才能画出真实阻塞画像。光靠 CPU 或 heap profile 会漏掉“不占 CPU 却卡死”的关键路径。
怎么抓 block profile 才能反映真实阻塞点
阻塞不是“慢”，而是 goroutine 主动让出执行权、等待同步原语（channel send/recv、mutex、cond、timer）时被记录下来的快照。默认不开启，需显式触发：
-
go tool pprof http://localhost:6060/debug/pprof/block?seconds=30是最常用方式，但注意：它只记录采样期间发生过阻塞的 goroutine，且阻塞时间越长越容易被捕获 - 若服务请求少、阻塞短（比如平均 curl "http://localhost:6060/debug/pprof/block?debug=1" > block.pprof，这个不依赖时间窗口，直接 dump 当前所有阻塞状态
- 务必确认 HTTP handler 中已导入
_ "net/http/pprof"，否则/debug/pprof/block返回 404 - 生产环境慎用
?seconds=30，它会阻塞采集线程 30 秒；优先用?debug=1快照式采集
为什么 goroutine?debug=2 比 debug=1 更关键
/debug/pprof/goroutine?debug=1 只显示摘要（如 “250 goroutines”），而 debug=2 输出完整调用栈——这才是定位“谁在等谁”的唯一依据：
- 重点关注状态含
chan receive、semacquire、select、sync.runtime_SemacquireMutex的栈帧 - 如果大量 goroutine 停在
runtime.gopark+chan receive，大概率是 channel 未关闭或 sender 已退出但 receiver 还在循环读 - 若堆栈里反复出现
sync.(*Mutex).Lock→runtime.semacquire，说明存在锁竞争，不是单点阻塞，得结合mutexprofile 看 contention ns -
debug=2输出体积大，建议用grep -A5 -B5 "chan receive\|semacquire"快速过滤
mutex profile 怎么看出“争抢激烈”而非“只是用了锁”
mutex profile 不统计锁持有时间，而是统计“为获取锁而等待的总纳秒数”，数值高才代表真有竞争：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 采集命令：
go tool pprof http://localhost:6060/debug/pprof/mutex - 进入交互后，先输
top看 top 函数，再输list 函数名查具体哪行代码调用了(*Mutex).Lock - 关键指标是
contention=xxx（单位 ns），>1e6（1ms）就值得怀疑；若某函数 contention 占总值 80% 以上，基本就是热锁源 - 常见陷阱：把
sync.RWMutex当读锁用，却在写路径上频繁调用RUnlock导致 reader count 错乱，引发虚假阻塞 —— 这种问题mutexprofile 不会暴露，得靠goroutine?debug=2配合看
阻塞画像必须交叉验证，不能只信单一 profile
一个典型误判是：看到 block profile 里 time.Sleep 占比高，就以为是“故意休眠拖慢服务”。其实可能是超时控制逻辑正常工作，而真正卡住的是下游 HTTP client 的 conn.read —— 它在 block 里表现为 net.(*netFD).Read，但在 goroutine?debug=2 里才能看到它正等在 epollwait 上。
- 必做三连查：
goroutine?debug=2（找卡在哪）、block（确认是否真阻塞）、mutex（排除锁干扰） - 若发现大量 goroutine 卡在
runtime.chansend，别急着加 buffer，先检查接收端是否已 panic 或提前 return 且没 close channel - trace.out 文件虽直观，但对阻塞分析不如上述三者精准：它展示调度轨迹，不标记“为什么等”，只告诉你“等了多久”
真正难的不是采集数据，而是从 goroutine?debug=2 里那一屏又一屏的栈中，识别出哪些是“合理等待”、哪些是“泄漏信号”。比如 http.(*persistConn).readLoop 持续存在是正常的，但同一 conn 的 writeLoop 缺失，就暗示连接异常中断未清理。
