GoLand的Profile按钮不支持block分析，必须手动在main开头调用runtime.SetBlockProfileRate(1)、导入_net/http/pprof_、启动HTTP服务并用go tool pprof抓取/debug/pprof/block数据。
GoLand 里直接跑 pprof block 分析行不通
GoLand 自带的「Profile」按钮（那个小火焰图标）只支持 CPU 和 Memory profile，block、goroutine、mutex 这几类 profile 它压根不识别，点了也没反应。这不是配置问题，是 IDE 功能限制——它调用的是 runtime/pprof 的本地文件写入模式，而 block profile 必须走 HTTP 接口 + 显式采样率设置，两者机制不兼容。
必须手动启服务 + 用 go tool pprof 抓取
真要分析 goroutine 阻塞点，得绕过 GoLand 的 Profile 界面，自己搭 HTTP 端点再命令行抓数据。关键动作就三步：
- 在
main()最开头（任何go语句之前）加runtime.SetBlockProfileRate(1)；生产环境建议设为100或1000，避免性能开销 - 导入
_ "net/http/pprof"（注意下划线，不是"net/http/pprof"） - 确保程序监听了 HTTP 端口（比如
:6060），且没被框架（Gin/Echo）的路由覆盖——如果用了自定义http.ServeMux，得手动挂载pprof路由
启动后访问 http://localhost:6060/debug/pprof/block?seconds=30，用 wget 或 curl 抓下来，再用命令行分析：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
go tool pprof -http=:8081 block.prof
为什么看到的都是 runtime.gopark，而不是业务函数？
block profile 统计的是阻塞总时长，不是当前卡住的 goroutine 列表。你看到堆栈底部全是 runtime.gopark 正常，重点要看它上面紧挨着的那一层——那才是业务入口：
- 如果上面是
sync.(*Mutex).Lock，再往上是UpdateUserCache，问题就在UpdateUserCache没及时 unlock - 如果上面是
net.(*pollDesc).wait，说明有没设超时的conn.Read()或http.Client.Do() - 如果上面是
chan receive，且再往上是handleOrder，大概率是往无缓冲 channel 发送，但接收方已退出或没启动
别只盯着 flat 值，sum 才反映整个调用链的阻塞累积量。
GoLand 只能辅助，不能替代手动验证
你可以把 GoLand 当作代码编辑器和调试器用：在疑似阻塞的函数里打断点、看变量、查锁状态；但它没法替你完成 SetBlockProfileRate 的时机控制，也没法绕过 HTTP 注册逻辑。最易漏掉的其实是「SetBlockProfileRate 放太晚」——比如写在 HTTP server 启动之后，结果压测时 profile 里全是底层调用，业务函数一个不出现。这点必须手写代码控制，IDE 帮不上忙。
