runtime.SetBlockProfileRate 是什么，什么时候该开
它不是开关，而是采样率控制开关——设为 0 表示关闭阻塞分析；设为 1 表示每个阻塞事件都记录；设为 100 表示平均每 100 次阻塞才记一次。真实场景中，设成 1 会严重拖慢程序（尤其高并发服务），而设成 0 就等于没开。合理起点通常是 10 或 20，兼顾可观测性与性能损耗。
怎么安全地开启并导出阻塞 profile
别在启动时硬编码设死，也别用全局常量。正确做法是运行时动态控制，配合 HTTP pprof 端点或信号触发：
- 先确保已注册 pprof：导入
"net/http/pprof"并启动http.ListenAndServe(":6060", nil) - 用环境变量或配置项控制初始值，例如：
os.Setenv("GODEBUG", "blockprofile=1")不起作用，必须调用runtime.SetBlockProfileRate() - 导出前务必先设好率，再等几秒让程序跑起来产生真实阻塞，否则 profile 可能为空
- 导出命令：
wget "http://localhost:6060/debug/pprof/block?seconds=30" -O block.prof
常见误判：为什么 profile 显示一堆 semacquire 却没找到业务代码
semacquire 是 Go runtime 底层的信号量等待，它本身不指向你的函数——真正要查的是它上面的调用栈。容易踩的坑有：
- 没开启 goroutine stack trace：默认
runtime.SetBlockProfileRate只记录阻塞位置，不自动抓完整栈；需配合go tool pprof -http=:8080 block.prof查看火焰图才能展开 - 阻塞发生在系统调用（如
read、accept）上，但你代码里没显式写net.Conn.Read——可能是第三方库（比如database/sql的连接池等待）或日志同步写导致 - 误把 mutex 等待当成本质阻塞：Go 的
sync.Mutex争用不会出现在 block profile 中，它走的是 mutex profile（用/debug/pprof/mutex）
和 runtime.SetMutexProfileFraction 别混用
两者解决的问题不同，profile 数据源也不同：
立即学习“go语言免费学习笔记（深入）”；
-
runtime.SetBlockProfileRate抓的是 goroutine 因 channel send/recv、锁等待（非 mutex）、syscall 等进入休眠的时机 -
runtime.SetMutexProfileFraction抓的是sync.Mutex和sync.RWMutex的争用统计，单位是「被阻塞的锁操作占比」 - 同时开启时，block profile 不会包含 mutex 等待细节；mutex profile 也不会反映 channel 阻塞——它们是正交的，不能互相替代
- 若怀疑是锁瓶颈，优先看 mutex profile；若看到大量 goroutine 停在 channel 上，才回头调高
SetBlockProfileRate
真正难的不是设那个数字，而是从几十层 runtime 栈里识别出哪一行业务代码触发了底层阻塞。profile 文件里最上面几行永远是 runtime.gopark，得往下翻十来层才能看到自己的函数名——这点很容易在第一次分析时错过。
