需手动调用 runtime.SetBlockProfileRate(1)（调试环境）或至少 100（线上），并确保启用 pprof HTTP handler（/debug/pprof/block），配合压测持续抓取，结合 go tool pprof 分析阻塞根因，注意区分 block 与 mutex profile。
怎么开启 Block Profile 并确保它真能捕获到阻塞
Block Profile 不是默认开启的，而且默认采样率极低（1/1000），大多数轻量级阻塞根本不会被记录。不手动调高 runtime.SetBlockProfileRate，你看到的 profile 很可能是空的或严重失真。
实操建议：
- 在程序启动早期（比如
main函数开头）调用runtime.SetBlockProfileRate(1)，让每次阻塞都记录——仅限调试环境，线上慎用 - 若担心性能开销，至少设为
100（即平均每 100 纳秒阻塞才记一次），比默认的1（单位是纳秒？错，是「每阻塞 1 微秒采样一次」，实际默认值是1e6，即 1 毫秒）更敏感 - 确认你的服务确实启用了 pprof HTTP handler，路径通常是
/debug/pprof/block，直接 curl 或浏览器访问该地址会触发一次快照 - 别只看单次快照：阻塞是瞬态现象，要持续压测 + 多次抓取，否则容易漏掉偶发长阻塞
看懂 block profile 输出里谁在等、等什么
拿到 curl http://localhost:6060/debug/pprof/block?seconds=30 > block.pb.gz 后，用 go tool pprof block.pb.gz 进入交互模式，top 显示的是「累计阻塞时间最长的调用栈」，不是 CPU 占用高——这点极易混淆。
关键点：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
runtime.gopark是阻塞起点，往上翻栈才能看到业务代码在哪调用了sync.Mutex.Lock、chan receive、net.Conn.Read等 - 如果 top 几名全是
selectgo或chanrecv，大概率是 goroutine 在空转等 channel，检查有没有未关闭的 channel 或漏掉的default分支 - 看到大量
semacquire调用，说明竞争集中在某个sync.Mutex或sync.RWMutex上，注意看锁保护的临界区是否过大、是否误将 IO 操作放进了锁内 - HTTP server 中常见
net/http.(*conn).serve长时间 park，往往是因为 handler 里同步调用了慢后端（如没设 timeout 的 HTTP client）或死循环
为什么本地复现不了线上 block profile 的热点
Block Profile 对负载敏感：低 QPS 下 goroutine 阻塞时间短、频次低，采样不到；而线上真实流量下，锁争用、channel 缓冲区满、DB 连接池耗尽等问题才会集中暴露。
排查时必须匹配场景：
- 用和线上一致的压测工具（如
hey -z 30s -q 100 -c 50）模拟并发，而不是只跑单请求 - 确认 GOMAXPROCS 设置与线上一致，否则调度行为不同，阻塞表现也会偏移
- 检查是否启用了
GODEBUG=schedtrace=1000辅助观察 goroutine 调度延迟，有时 block profile 看似平静，但schedtrace会显示大量goroutines blocked on chan send - 注意容器环境：Kubernetes 中 cgroup 限制 CPU 导致调度延迟升高，可能让原本短暂的阻塞被放大成可观测的 block profile 样本
block profile 和 mutex profile 别混着用
两者目标不同：block profile 关注「goroutine 因什么原因为了多久而挂起」，mutex profile 只统计「哪把锁被争抢最久、平均阻塞了多久」。一个查等待原因，一个查锁本身。
典型误用：
- 看到
mutex profile里某锁 hot 就急着优化，但实际问题可能是该锁保护的函数里调用了阻塞 IO，此时改锁无用，得拆逻辑 - 用
go tool pprof --alloc_space去分析 block 数据——不行，格式不兼容，会报错unrecognized profile format - 把
/debug/pprof/block和/debug/pprof/mutex抓同一时刻快照就认为数据可比——不对，它们采样机制独立，rate 设置也不同，需分开理解
真正卡顿的根因，往往藏在 block profile 里第三层调用栈之后，而人眼习惯只扫前两行。多按 list 看源码上下文，比盯着 top 10 更管用。
