Go编译后无法输出调试信息的核心原因是二进制被strip掉DWARF信息或工具链不支持DWARF v5；-ldflags="-s -w"会剥离调试段，Go 1.25+默认DWARF v5在Windows易被误判，pprof需显式传入未strip二进制。
Go 编译后无法输出调试信息，核心原因只有两个：二进制被 strip 掉了 DWARF 调试信息，或者运行环境/工具链不支持当前的 DWARF 版本（尤其是 Go 1.25+ 默认启用的 DWARF v5）。不是代码没写 fmt.Println，也不是日志库配置错了——是调试信息根本没进去，或进去了也读不出来。
go build 时意外丢掉了调试信息
默认 go build 会保留完整 DWARF 信息，但只要加了 -ldflags="-s -w"，就会同时剥离符号表和调试段：
-
-s：去掉符号表（symbol table） -
-w：去掉 DWARF 调试信息（debug info）
这两个 flag 常被误用于“减小体积”，结果导致 dlv 启动失败、pprof list 报 No source information、IDE 断点全灰。确认是否中招，执行：
file ./mybinary
若输出含 stripped，说明调试信息已丢失；正常应显示 not stripped。
立即学习“go语言免费学习笔记（深入）”；
✅ 正确做法：如需精简体积，优先用 upx 压缩未 strip 的二进制，而非用 -ldflags="-s -w" 粗暴移除调试能力。
Go 1.25+ 默认启用 DWARF v5，Windows 上直接报错
在 Windows 下编译出的二进制，若用 Go 1.25+，可能触发系统级拦截：“此应用无法在你的电脑上运行”。这不是病毒，是 PE 文件头里嵌入的 DWARF v5 段被 Windows 安全机制（SmartScreen、核心隔离）误判为异常结构。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
临时绕过方法（开发阶段有效）：
go env -w GOEXPERIMENT=nodwarf5
之后再 go build，就退回兼容性更好的 DWARF v4。注意：该设置仅影响新编译的二进制，已生成的文件不会自动降级。
⚠️ 不建议长期关闭 nodwarf5：DWARF v5 对复杂结构体、泛型类型调试更准确，只是 Windows 工具链跟进慢。Mac/Linux 用户基本无感。
pprof list 失败：不是远程问题，是本地没带二进制
go tool pprof 远程采集 profile 数据后，执行 list MyFunc 报错 No source information，根本不是网络或权限问题，而是你没传本地可执行文件：
- 错误用法：
go tool pprof http://localhost:6060/debug/pprof/profile（纯 HTTP 模式，无二进制） - 正确用法：
go tool pprof ./mybinary http://localhost:6060/debug/pprof/profile（显式提供未 strip 的二进制）
pprof 靠二进制里的 DWARF 找源码路径和行号。如果构建环境和分析环境 GOPATH / module root 不一致，它甚至可能找不到 main.go ——此时别急着改 GODEBUG=pprofpath=...，先确保你在原构建目录下运行 pprof。
真正卡住人的，往往不是“怎么加调试信息”，而是“为什么加了也看不见”：DWARF v5 在 Windows 上静默失效、strip 后的二进制连 dlv 都拒绝加载、pprof 离开原始二进制就变盲人——这些都不是配置遗漏，是工具链版本与平台限制的硬边界。盯住 file 输出、go env GOEXPERIMENT 和是否显式传了二进制，比反复重装 IDE 有用得多。
