Go火焰图需先用go tool pprof提取栈再用flamegraph.pl渲染，Web界面默认隐藏且依赖外部脚本；符号被strip会导致函数名显示为?或[unknown]；线上应限采样时长并管控访问。
Go 火焰图不是开箱即用的功能，它需要两步转换：先用 go tool pprof 提取原始采样栈，再用 flamegraph.pl 渲染 SVG；直接访问 /ui/flamegraph 或点 Web 界面的“Flame Graph”按钮，只在特定版本和配置下有效，多数生产环境实际走不通。
为什么 go tool pprof -http=:8080 里看不到火焰图按钮
Go 自带的 pprof Web 界面（go tool pprof -http 启动的）从 Go 1.21 开始默认隐藏火焰图入口，除非你手动传入 -symbolize=none 或满足符号解析条件。更关键的是：它依赖本地有 flamegraph.pl 脚本且路径可访问——而这个脚本根本不在 Go 安装包里，得单独下载。
- 常见错误现象：
view → Flame Graph灰掉、点击无反应、控制台报flamegraph: command not found - 真实使用场景：线上服务压测后分析 CPU 热点，或本地复现高延迟时定位 goroutine 阻塞源头
- 参数差异：
-http模式只是个可视化壳子，真正生成火焰图必须靠外部 Perl 脚本；而-raw -lines才是导出可绘图数据的唯一可靠方式 - 性能影响：Web 界面实时渲染大 profile 文件（>50MB）会卡死浏览器，建议一律导出为 SVG 离线查看
go tool pprof -raw -lines 导出的 stacks.txt 为什么全是 ? 或 [unknown]
这是符号表被 strip 掉的典型表现，不是采集失败，而是编译时加了 -ldflags="-s" 或 -ldflags="-w"。没有符号，pprof 就无法把地址映射回函数名，火焰图上所有宽度都堆在顶层，完全没法看。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须去掉编译参数：
go build -o server ./main.go（不加任何-ldflags） - 若必须 strip（如安全合规），可用
go build -buildmode=pie -ldflags="-linkmode external"保留部分调试信息 - 验证方法：运行
nm -C your_binary | head -n 5，看到一堆函数名说明符号正常；全是数字地址则失败 - Go 1.22+ 新增
go tool pprof --symbols可强制尝试符号恢复，但成功率低，不如从编译源头解决
线上服务怎么安全采 CPU 火焰图，又不拖垮接口
线上不能跑默认 30 秒的 profile?seconds=30，尤其高 QPS 服务——pprof CPU profiling 基于 setitimer 信号中断，每秒 100 次采样，30 秒就是 3000 次上下文切换，足够让 P99 延迟翻倍。
立即学习“go语言免费学习笔记（深入）”；
- 实操建议：用
?seconds=5&debug=1，5 秒够暴露大部分热点；debug=1 能返回采样数，确认是否有效（比如返回samples=498表示基本正常） - 必须管控访问：Nginx 层加 IP 白名单，或改用
go tool pprof直连本地 profile 文件（go tool pprof ./binary http://localhost:6060/debug/pprof/profile?seconds=5） - 别混用
runtime/trace和 pprof：前者是 goroutine 抢占采样，后者是信号中断，数据源不同，flamegraph.pl输入必须是 pprof 格式，trace 输出不兼容 - 容器环境注意：
/proc/self/maps权限需放开，否则符号解析失败，表现为部分栈帧显示为[vdso]或空行
最常被忽略的一点：火焰图宽 = 时间占比，但 Go 的 runtime 函数（如 runtime.mcall、runtime.gopark）占宽高，不等于业务代码有问题——得先看它上面紧邻的业务函数是谁；如果顶部全是 net/http 或 io.Copy，大概率是 I/O 等待，不是 CPU 瓶颈，该查网络或磁盘，而不是优化 for 循环。
