要看内存泄漏需用 heap profile 而非 CPU profile，抓取 /debug/pprof/heap 数据后用 pprof 分析 alloc_space 或 alloc_objects，避免只看 inuse_space。
go tool pprof 怎么看内存泄漏而不是 CPU 热点
默认 go tool pprof 打开的是 CPU profile，但内存泄漏得看 heap profile——很多人跑完 pprof 发现火焰图全是 runtime 代码，就以为没线索，其实是没切对 profile 类型。
实操上，先用 net/http/pprof 暴露 /debug/pprof/heap（注意不是 /debug/pprof/profile），抓取时加 -http 参数或直接 curl -s http://localhost:6060/debug/pprof/heap > heap.pb.gz；然后 go tool pprof heap.pb.gz 进入交互后，用 top 看 alloc_space（分配总量）或 top -cum 看持续存活对象，别只盯着 inuse_space——它只反映当前堆里还活着的，漏掉高频分配+快速释放的泄漏模式。
- 容易踩的坑：
go tool pprof默认加载的是inuse_space，但真正可疑的是alloc_objects或alloc_space的持续增长 - Web 视图里点 “View → Top” 后，右上角下拉菜单必须手动选
alloc_space，否则图形和数字对不上 - 如果程序没开
net/http/pprof，临时加一行import _ "net/http/pprof"并启动 HTTP server，比改代码埋点快得多
go tool trace 显示“no trace data” 或空白时间线
trace 数据不是自动采集的，必须显式调用 runtime/trace.Start 和 trace.Stop，且采集期间不能有 GC 停顿干扰——很多新手直接跑 go run main.go 后立刻 go tool trace trace.out，结果打开就是空的，因为根本没写数据。
正确做法是：在主逻辑前加 trace.Start(os.Stderr)（或写到文件），确保程序运行足够久（至少 1–2 秒），且中间没 panic 或提前 exit；结束前调用 trace.Stop()。更稳妥的是用 go run -gcflags="-l" -trace=trace.out main.go，绕过手动埋点。
- 常见错误现象：
go tool trace trace.out报failed to open trace file: EOF，说明文件为空，大概率是trace.Start没执行到就退出了 -
-trace编译参数生成的 trace 文件比手动生成的更完整，尤其包含调度器事件（如 Goroutine 创建/阻塞/唤醒） - trace UI 里按
w放大时间轴，按s切换视图（Goroutines / Network / Syscall），别只盯着默认的“Wall Time”
go tool cover 为什么 -race 和 -cover 不能一起用
go test -race -cover 会报错：flag provided but not defined: -race，这不是 bug，是工具链设计限制——go tool cover 是独立二进制，不识别 -race 标志；而 go test 的 -race 和 -cover 在底层走不同插桩路径，无法同时生效。
想兼顾竞态检测和覆盖率，只能分两步：先 go test -race 跑一遍，再 go test -coverprofile=cover.out 跑一遍。如果非要单次命令，用 go test -covermode=count -coverprofile=cover.out，然后人工检查高覆盖但未触发的分支是否可能藏竞态——这比强行合并在技术上更现实。
- 覆盖模式差异：
-covermode=count记录每行执行次数，适合找未覆盖路径；-covermode=atomic在并发测试中更准，但会略微拖慢速度 -
go tool cover -func=cover.out输出函数级覆盖率，比-html更快定位低覆盖函数 - CI 中建议把
-race和-cover拆成两个 job，避免误判“覆盖率达标就等于线程安全”
go tool 的子命令哪些是“真工具”，哪些只是包装器
go tool pprof、go tool trace、go tool cover 都是真实可执行文件（位于 $GOROOT/pkg/tool/$GOOS_$GOARCH/），但像 go tool vet、go tool compile 已被整合进 go build 流程，不再推荐直接调用——很多人查文档看到 go tool compile -S main.go 就去试，结果报错或输出不一致，是因为新版 Go 默认启用增量编译和缓存，绕过 go build 直接调 compile 会跳过关键步骤。
判断一个 go tool xxx 是否该直接用，看它有没有独立文档页（如 pprof、trace、cover 官方都有单独指南），以及是否依赖运行时数据（如 trace 依赖 trace 文件，pprof 依赖 profile 数据）。而 go tool nm、go tool objdump 这类反汇编工具仍可用，但要注意目标文件必须是 Go 编译出的（go build -o main main.go），不能是 C 链接进来的二进制。
- 容易混淆：
go tool dist是构建 Go 源码用的，普通项目完全用不到；go tool fix已废弃多年，别搜到旧教程就试 - 所有
go tool命令都要求 GOPATH 或 go modules 正确设置，否则可能提示cannot find package即使代码就在当前目录 - 用
go tool查路径：go tool dist env GOROOT比go env GOROOT更底层，适合调试工具链本身问题
真正难的不是记住每个子命令怎么敲，而是分清哪些数据源必须提前准备（比如 trace 文件得运行时生成、pprof 要服务端暴露接口）、哪些结果需要交叉验证（比如 cover 显示某行覆盖了，但 trace 里发现它总在系统调用后卡住）。工具只是探针，指针偏了，再亮的光也照不到根因。
