runtime.setblockprofilerate 是控制 go 阻塞事件采样频率的函数，设为 0 关闭、1 全采样、100 表示平均每 100 次阻塞采样 1 次；推荐调试时暂设 1，线上监控设为 1000 或更高，并配合 pprof 获取分析 block profile 数据。
runtime.SetBlockProfileRate 是什么，什么时候该开
runtime.SetBlockProfileRate 控制 Go 运行时采集 goroutine 阻塞事件（如 channel send/recv、mutex lock、syscall 等）的采样频率。它不是“开关”，而是一个采样率：设为 1 表示每次阻塞都记录；设为 0 表示完全关闭；设为 100 表示平均每 100 次阻塞采样 1 次。
实际调试中，0 或 1 都不推荐——前者没数据，后者性能开销极大（尤其高并发服务）。常见做法是启动时设为 1 用于复现问题，定位后调高（如 1000）做线上轻量监控。
- 仅当怀疑存在严重阻塞（如 p99 延迟突增、goroutine 数持续上涨）时启用
- 它不影响 CPU 或内存 profile，但会增加调度器负担，建议只在 debug build 或临时开启
- 必须在
main函数开头或init中调用，越早越好；运行中修改只影响后续采样
怎么获取和解析 block profile 数据
Go 自带 pprof 支持 block profile，但默认不暴露 HTTP 接口。需手动注册 handler 或写文件：
import _ "net/http/pprof"
<p>func main() {
runtime.SetBlockProfileRate(100) // 设定采样率
go func() {
http.ListenAndServe("localhost:6060", nil)
}()
// ... your app
}</p>
然后访问 http://localhost:6060/debug/pprof/block?debug=1 得到文本格式 raw data，或用 go tool pprof 可视化：
-
go tool pprof http://localhost:6060/debug/pprof/block进入交互式分析 -
top查看最耗时的阻塞调用栈 -
web生成火焰图（需安装 graphviz） - 注意：返回的 profile 默认只包含“当前仍阻塞”的 goroutine；若想捕获历史阻塞热点，需配合
-seconds=30参数延长采样窗口
常见误判：为什么看到大量 netpoll 或 runtime.gopark
runtime.gopark 和 netpoll 在 block profile 里高频出现，不等于有问题——它们是 Go 调度器正常休眠机制。真正要关注的是你代码里的调用点，比如：
- 阻塞在
ch 上？检查 channel 容量和接收方是否卡住 - 停在
sync.Mutex.Lock？看锁持有时间是否过长，或是否存在锁竞争热点 - 卡在
net.Conn.Read？确认是否未设置ReadDeadline导致无限等待 - profile 中显示
runtime.chansend占比高，但调用栈顶层是你自己的sendToChannel函数——这才是根因
关键：别盯着底层函数名，顺着调用栈往上翻，找到第一个属于你项目包的函数名。
生产环境小心这三件事
线上开 runtime.SetBlockProfileRate 不是“开个开关”那么简单：
- 采样率设太高（如
1）会导致 GC 压力陡增，甚至触发 STW 延长——实测 1k QPS 服务开启rate=1后 GC pause 增加 3–5ms - block profile 默认只保存最近 500 个样本，高频阻塞场景下旧数据被覆盖，可能漏掉偶发长阻塞；可用
runtime.SetMutexProfileFraction辅助交叉验证 - 容器环境下，
/debug/pprof端口需显式暴露且限制 IP 白名单，否则可能被扫描利用
最稳妥的做法：用 pprof.StartCPUProfile + runtime.SetBlockProfileRate 组合，在问题复现窗口内精准启停，而不是常驻开启。
