GoLand 中 pprof 的 block/mutex profile 默认不生效，因 runtime 采样率未开启；需在 main 或 init 中显式调用 SetBlockProfileRate(1) 和 SetMutexProfileFraction(1)，并确保 HTTP 服务独立暴露、运行配置正确。
为什么在 GoLand 里直接跑 pprof 会失败
GoLand 默认运行配置不启用 runtime.SetBlockProfileRate(1) 或 runtime.SetMutexProfileFraction(1)，导致访问 /debug/pprof/block 或 /debug/pprof/mutex 返回空数据——不是路径错，是采样率没开。pprof 的 block/mutex profile 默认关闭，必须显式开启，否则无论怎么访问都看不到锁等待堆栈。
- block profile 默认 rate = 0，需在程序启动时调用
runtime.SetBlockProfileRate(1)（1 表示每次阻塞都采样） - mutex profile 默认 fraction = 0，需调用
runtime.SetMutexProfileFraction(1)（1 表示每次锁争用都记录） - 这两个调用必须在任何 goroutine 启动前执行，建议放在
main()开头或init()里 - GoLand 的「Run」配置不会自动注入这些设置；仅靠导入
_ "net/http/pprof"不够
GoLand 中正确启用 block/mutex profile 的三步操作
不是加个 import 就完事，得让 runtime 知道你要采锁。以下操作缺一不可：
- 在代码中显式设置采样率：在
main()函数第一行加runtime.SetBlockProfileRate(1)和/或runtime.SetMutexProfileFraction(1) - 确保 pprof HTTP 服务已暴露：用
http.ListenAndServe("127.0.0.1:6060", nil)启一个独立端口，别复用主服务 mux - GoLand 运行配置里勾选「Allow running in background」并确认未勾选「Redirect input」——否则
fmt.Scanln类阻塞会卡住调试流程
在 GoLand 里快速验证 block profile 是否生效
别等线上出问题才试。本地写个最小复现：起两个 goroutine，一个持锁 sleep，一个等锁，然后立刻 curl。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 写一段故意阻塞的代码，比如用
sync.Mutex+time.Sleep模拟锁等待 - 启动后立即执行：
curl "http://127.0.0.1:6060/debug/pprof/block?debug=1"，应返回非空文本，含sync.(*Mutex).Lock和等待 goroutine 栈 - 若返回空或只有
no samples to report，说明SetBlockProfileRate没生效或调用太晚 - GoLand 调试时可在该函数入口打条件断点，确认它确实被执行了
分析结果时最易忽略的细节
即使拿到了 block profile 数据，也容易误读：火焰图或 top 列表里看到 runtime.futex 不代表内核问题，大概率是你自己的锁没释放，或者 channel recv/send 卡住了。
-
/debug/pprof/block?debug=2返回的是“当前所有被阻塞的 goroutine”快照，不是历史累计——它只反映那一瞬间谁在等 - 如果阻塞时间极短（SetBlockProfileRate(1) 也可能漏掉，这时要结合
/debug/pprof/goroutine?debug=2看长期卡在chan receive或select的 goroutine - GoLand 自带的「Services」工具窗口可右键添加 pprof URL，但记得手动刷新，它不会自动轮询
- 真正定位到业务函数名的前提是：编译时没加
-ldflags="-s -w"，且go tool pprof分析时传入的是原始二进制文件，不是 profile 文件本身
