当使用 `go tool pprof` 远程采集性能数据时，若执行 `list` 命令提示 “no source information”，根本原因是未提供可执行二进制文件——pprof 需要该二进制中的 dwarf 调试信息才能映射符号到源码。
在 go 应用中启用 net/http/pprof 后，通过 HTTP 接口（如 http://localhost:9000/debug/pprof/profile）可成功采集 CPU、内存等 profile 数据，top, graph, web 等命令也能正常工作。但一旦尝试使用 list MyFunc 查看具体函数源码，却常遇到如下错误：
(pprof) list MyFunc No source information for mypkg.MyFunc这是因为：远程采集的 profile 数据本身不包含源码路径、行号或调试符号信息；pprof 必须结合原始可执行文件（含完整 DWARF 信息）才能完成符号解析与源码定位。
✅ 正确做法是：在调用 go tool pprof 时，显式传入本地构建的二进制文件路径：
go tool pprof ./mybinary http://localhost:9000/debug/pprof/profile⚠️ 注意：./mybinary 必须是 未 strip 且保留调试信息 的可执行文件。默认 go build 生成的二进制已包含必要 DWARF（Go 1.10+ 默认启用），但以下情况会导致失败：使用 -ldflags=”-s -w” 构建（剥离符号和调试信息）；二进制被 strip 工具处理过；本地二进制与远程运行版本不一致（如修改后未重新编译）。
验证二进制是否含调试信息，可运行：
立即学习“go语言免费学习笔记（深入）”；
file ./mybinary # 应显示 "with debug_info" readelf -S ./mybinary | grep debug # 应列出 .debug_* 段进入 pprof 交互模式后，即可正常使用：
(pprof) list MyFunc Total: 260ms ROUTINE ======================== mypkg.MyFunc in mypkg/main.go 260ms 260ms (flat, cum) 100% of Total . . 43:func MyFunc() { . . 44: time.Sleep(200 * time.Millisecond) . . 45:}? 补充建议：
- 开发/测试环境务必使用 go build 默认行为（不加 -ldflags=”-s -w”）；
- 若需精简生产二进制，建议仅在发布前 strip，并保留一份带调试信息的归档版本专供 profiling 分析；
- 可配合 -http=”:8080″ 启动 Web UI：go tool pprof -http=”:8080″ ./mybinary http://localhost:9000/debug/pprof/profile，图形化查看火焰图及源码高亮。
掌握这一关键细节，即可让 Go 性能分析真正“看得见、读得懂”，大幅提升定位瓶颈函数的效率。