pprof火焰图需显式注册runtime/pprof并暴露HTTP接口，内存分析依赖持续采样而非快照，应区分inuse_space（泄漏风险）与alloc_space（分配压力），且采样前须确保业务稳定运行。
pprof 启动时必须显式注册 runtime/pprof 并暴露 HTTP 接口
Go 默认不开启内存分析，net/http/pprof 只是提供 Web 路由入口，真正采集堆信息靠 runtime/pprof 的后台采样。没手动调用 runtime/pprof.StartCPUProfile 或触发堆 dump，火焰图里就只有空帧。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
main()开头加runtime.GC()，避免启动时残留对象干扰首次采样 - 用
http.ListenAndServe(":6060", nil)启动后，确保已导入_ "net/http/pprof"（下划线导入触发 init 注册） - 不要只依赖
go tool pprof http://localhost:6060/debug/pprof/heap—— 这只是快照，火焰图需要持续采样，应改用go tool pprof http://localhost:6060/debug/pprof/heap?seconds=30
生成火焰图前必须安装 Graphviz 且 dot 命令要能被 pprof 找到
go tool pprof 本身不绘图，它调用系统 dot（Graphviz 的命令行工具）把 profile 数据转成 SVG。没装 Graphviz、PATH 里没有 dot、或版本太老（generating report 或报错 failed to execute dot。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- macOS 用
brew install graphviz；Ubuntu/Debian 用apt install graphviz；Windows 下从 graphviz.org 下载 MSI 安装，并勾选「Add Graphviz to the system PATH」 - 装完立刻终端执行
dot -V确认输出类似dot - graphviz version 7.0.5 (20230918.0245) - 如果
dot在非标准路径（比如 Windows 装在C:\Program Files\Graphviz\bin\dot.exe），需设环境变量PPROF_BINARY_PATH指向该目录，例如set PPROF_BINARY_PATH=C:\Program Files\Graphviz\bin
go tool pprof -http 启动的 Web UI 不等于火焰图，得点「Flame graph」标签再生成
很多人跑完 go tool pprof -http=:8080 <profile> 就以为完事了，但默认打开的是「Top」视图，显示函数耗时排序。火焰图藏在右上角「Flame graph」按钮里，而且首次点击会触发本地 dot 渲染 —— 如果没装 Graphviz，页面只会空白或报错，不会提示缺依赖。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用命令行直接导出 SVG：
go tool pprof -svg <profile> > flame.svg，省去 Web 交互环节 - 若用 Web UI，点「Flame graph」后留意浏览器控制台是否有
Failed to load resource或 Network 标签里dot请求失败 - 对大 profile（>100MB），SVG 渲染可能卡顿，可改用
-weblist查看带源码行号的调用链，比火焰图更准确定位分配点
内存火焰图的关键是区分 inuse_space 和 alloc_space，选错指标会误判问题
/debug/pprof/heap 提供两个核心采样模式：inuse_space（当前存活对象总字节数）反映内存泄漏风险；alloc_space（累计分配字节数）反映高频小对象分配压力。用 alloc_space 看火焰图，常看到 make、newobject 占满顶层，但这不等于泄漏 —— Go GC 会回收，真正要盯的是 inuse_space 中长期驻留的结构体。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 查泄漏：用
go tool pprof http://localhost:6060/debug/pprof/heap?gc=1（强制 GC 后采样），并确保 URL 含?debug=1显示符号名 - 查分配热点：用
go tool pprof http://localhost:6060/debug/pprof/allocs，注意这是累计值，需对比两次采样差值才有意义 - 火焰图中若某函数下大量
runtime.mallocgc，先看它是否调用了make([]byte, N)且 N 是变量 —— 这类动态分配极易触发逃逸和堆增长
最常被跳过的一步：采样前没等程序运行足够久，或者没触发真实业务负载。火焰图不是启动即拍，它需要稳定态下的内存行为 —— 比如处理完 1000 个请求后再抓 heap，否则看到的全是初始化代码的噪声。
