block profile统计的是同步原语阻塞总时长而非goroutine状态，需结合调用栈判断锁或channel阻塞，并确认pprof已启用、阻塞超1ms且程序处于真实负载。
怎么看 Goroutine 是不是真卡住了
Go 的 runtime/pprof 提供的 block profile 不是“哪些 goroutine 在阻塞”，而是“哪些调用在等待锁、channel、syscall 等同步原语时花了最多时间”。它统计的是阻塞**总时长**，不是 goroutine 数量或存活状态。所以看到某个 sync.Mutex.Lock 占比高，不等于有 100 个 goroutine 堵在那儿——可能只是 1 个 goroutine 反复抢锁失败、每次等 10ms，累积出 1s；也可能真是 10 个 goroutine 同时堵了 100ms。
实操建议：
- 先用
go tool pprof http://localhost:6060/debug/pprof/block?seconds=30抓 30 秒 block profile（确保程序正在跑真实负载） - 进 pprof 交互界面后，用
top看耗时 top 函数，再用list <func>定位具体行 - 重点看是不是反复出现在
sync.(*Mutex).Lock、runtime.gopark（常对应 channel recv/send）、net.(*pollDesc).wait（网络 I/O 阻塞） - 别只盯函数名，要看调用栈深度：如果
Lock上面总跟着同一个业务函数（比如UpdateUserCache），那问题大概率在那个函数里没释放锁
为什么开了 block profile 还看不到阻塞点
block profile 默认关闭，且只有发生真实阻塞（park）才会采样。如果 goroutine 是“逻辑卡住”——比如死循环、空 select、无限重试无 sleep——它根本不会进入 park 状态，block profile 就完全捕获不到。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- profile 文件里全是
runtime.gopark，但没业务函数，说明阻塞发生在标准库底层（如 net/http server loop），得结合 trace 或 goroutine dump 看 - 抓了 60 秒 profile，
sampled X out of Y goroutines显示采样数为 0，说明期间没发生可测量的阻塞（可能负载太轻，或代码压根没走同步路径） - 用了
http.DefaultServeMux但没开/debug/pprof，导致/debug/pprof/block返回 404
必须检查：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 服务是否真的启用了 pprof：确认已导入
_ "net/http/pprof"，且http.ListenAndServe对应端口已暴露 - 阻塞是否足够久：默认采样阈值是 1ms，小于 1ms 的等待会被忽略；可通过
runtime.SetBlockProfileRate(1)降低到 1 纳秒级（仅调试用，线上禁用） - 是否在非阻塞路径上浪费 CPU：这种得切到
cpuprofile 或trace
sync.Mutex 和 channel 阻塞在 profile 里怎么区分
block profile 不会直接标出 “这是 mutex” 或 “这是 channel”，全靠调用栈推断。关键线索在函数签名和上下文：
-
sync.(*Mutex).Lock出现在栈顶 → 基本就是互斥锁争用；如果下面紧跟着runtime.semacquire1，说明在等信号量（mutex 底层实现） -
runtime.chansend或runtime.chanrecv→ channel 阻塞；若后面是runtime.gopark+chan send/recv，基本确定是无缓冲 channel 或接收方未就绪 -
net.(*conn).Read/Write→ 网络 I/O 阻塞，常见于未设 timeout 的 TCP 连接或慢下游
一个典型误判场景：
- 看到
runtime.selectgo占比高，容易以为是 select 语法问题；其实它只是调度器入口，真正要看的是 select 里各个 case 调用的函数（比如<-ch对应runtime.chanrecv，time.After对应runtime.timerProc） - channel 阻塞如果发生在 goroutine 刚启动时（比如
go func() { ch ），而主 goroutine 没及时 <code><-ch，block profile 会显示该 goroutine 的 send 耗时很长——但实际是它被调度后立刻 park，一直没唤醒
block profile 对线上服务的影响有多大
开启 block profile 本身开销极小，但 SetBlockProfileRate 设得太低（比如 1）会让每次锁、channel 操作都触发采样逻辑，CPU 和内存开销陡增，线上绝对不能长期开着。默认 rate 是 1e6（1ms），意味着平均每 1ms 阻塞才记录一次，对性能影响可忽略。
实操红线：
- 线上只用默认 rate，除非明确要定位偶发长阻塞，才临时调低并立即恢复
- 不要用
pprof.Lookup("block").WriteTo手动 dump——这会阻塞所有 goroutine，可能引发雪崩 - block profile 数据是增量累积的，两次请求之间不自动清空；如果想测单次请求，得先调用
pprof.StopCPUProfile()类似逻辑（但 block 没 stop 接口），更稳妥是重启服务或换新进程 - goroutine 数暴涨时，block profile 可能因采样点过多变慢，此时优先看
/debug/pprof/goroutine?debug=2的完整堆栈，找重复模式
最常被忽略的一点：block profile 只告诉你“哪里等得久”，不告诉你“为什么等不到”。比如 channel send 阻塞，得顺着代码查是谁该 recv 却没 recv——可能是 goroutine panic 退出、逻辑跳过、或者根本没起 goroutine。这时候 profile 是起点，不是终点。
