当使用 `go tool pprof` 分析 http 服务的性能数据时，若执行 `list` 命令提示“no source information”，根本原因是未提供可执行二进制文件；只需显式传入本地编译的二进制路径，pprof 即可关联 dwarf 调试信息并正确解析源码。
在 Go 应用中启用 net/http/pprof 后，我们常通过 go tool pprof 获取 CPU、内存等分析数据。例如：
go tool pprof http://localhost:9000/debug/pprof/profile
该命令能成功加载 profile 数据，并支持 top10、web、svg 等交互式指令——但一旦尝试查看具体函数源码（如 list MyFunc），却报错：
No source information for mypkg.MyFunc
问题本质：pprof 默认仅从 HTTP 接口下载采样数据（如 profile 文件），而该文件本身不包含源码路径、行号映射或符号表信息。要实现源码级分析（如 list、disasm 或 peek），pprof 必须结合原始二进制文件中的 DWARF 调试信息进行符号解析。
✅ 正确做法是显式指定本地构建的可执行文件：
# 先确保已构建二进制（推荐禁用优化以保留完整调试信息） go build -gcflags="all=-N -l" -o mybinary ./main.go # 再运行 pprof，并将二进制作为第一个参数 go tool pprof mybinary http://localhost:9000/debug/pprof/profile
? 提示：-gcflags="all=-N -l" 参数用于禁用内联（-N）和编译器优化（-l），显著提升源码行号准确性与调试体验，生产环境 profiling 可酌情省略，但开发/调试阶段强烈建议保留。
此时进入 pprof 交互模式后，list MyFunc 将正常显示带行号的源码片段，web 命令生成的火焰图也可点击跳转至对应源码位置。
⚠️ 注意事项：
- 二进制文件必须与正在运行的服务完全一致（相同 commit、相同构建环境），否则符号偏移可能错位；
- 若使用 go run main.go 启动服务，Go 会生成临时二进制，路径不可控；务必使用 go build 显式构建并复用该文件；
- GOPATH 或模块路径设置对 pprof 源码定位无直接影响——pprof 依赖的是二进制内嵌的 PWD 和 GOROOT 编译时路径，而非当前环境变量；
- 在容器或远程环境中调试时，需将本地构建的二进制（含调试信息）与 profile 数据一并获取，避免因路径差异导致源码缺失。
? 总结：go tool pprof
