go version -m 输出二进制中嵌入的构建元信息，仅含主模块名、Go版本及编译时main module的直接依赖版本，不反映运行时真实依赖。
go version -m 输出的是什么，为什么不能直接当依赖版本用
执行 go version -m 时，它只显示当前二进制文件的构建元信息：主模块名、Go 编译器版本、以及**编译时 main module 的 go.mod 中记录的直接依赖版本**。它不解析运行时实际加载的模块（比如通过 plugin 或 embed 加载的）、也不处理 replace / indirect / retract 等修饰，更不会递归展开所有 transitive 依赖的真实版本。
常见错误现象：go version -m mybin 显示 github.com/sirupsen/logrus v1.9.0，但 runtime 包里实际用的是 v1.13.0 —— 因为 v1.9.0 是构建时“看到”的版本，而最终加载的是 vendor 或 GOPATH 下的旧版，或被其他模块升级覆盖了。
- 使用场景：适合快速确认“这个二进制是用哪个主模块、哪个 Go 版本构建的”，不是依赖审计工具
- 参数差异：
-m必须跟二进制路径；加-v会额外显示 build settings（如 CGO_ENABLED），但不增加依赖深度 - 性能影响：几乎无开销，纯读取二进制中嵌入的
runtime.buildinfo数据段
真正要查运行时依赖版本，得靠 go version -m 配合 go list
go version -m 本身不支持递归分析，但你可以用它输出的主模块路径，再结合 go list -m all 在源码目录下还原构建视图。前提是二进制构建时没用 -trimpath 且保留了 go.sum 和 go.mod 上下文（绝大多数 CI 构建会删掉）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 如果还有源码：进项目根目录，运行
go list -m all | grep 'logrus'，结果比go version -m更准，因为走的是 module graph resolver - 如果只剩二进制且想逆向：先用
go version -m mybin看主模块名（如example.com/cmd/mybin），再尝试在 GOPROXY 可达环境下执行go mod download example.com/cmd/mybin@latest，再进下载目录跑go list -m all - 注意兼容性：
go list -m all要求 Go 1.17+，且模块必须可解析（不能有本地 replace 指向不存在路径）
二进制里没有 go.mod？那就得看 runtime/debug.ReadBuildInfo()
很多生产二进制为了减小体积会加 -ldflags="-s -w"，这会 strip 掉 build info —— 此时 go version -m 仍能输出基础信息，但 go list 方法彻底失效。唯一可靠方式是让程序自己暴露依赖信息。
标准做法是在 main 包里加一段启动逻辑：
import "runtime/debug"<br><br>func init() {<br> if info, ok := debug.ReadBuildInfo(); ok {<br> for _, dep := range info.Deps {<br> fmt.Printf("%s %s\n", dep.Path, dep.Version)<br> }<br> }<br>}
关键点：
-
debug.ReadBuildInfo()读的是编译时 embed 到二进制里的结构体，不受-s影响，但会被-w去掉符号表（不影响该函数） -
dep.Version是模块实际参与构建的版本，含+incompatible标记，比go version -m的输出更接近真实依赖树 - 如果用了
go install或go build -buildmode=plugin，该方法依然有效；但 cross-compile 时需确保 target 平台能运行 debug 包
第三方工具补充：goversion 与 delve 调试时查依赖
go version -m 是官方最轻量的入口，但真要分析陌生二进制，得靠外部工具辅助验证。
推荐两个实用组合：
-
goversion（非官方 CLI）：用goversion mybin可提取更细粒度信息，比如CGO_ENABLED、GOOS/GOARCH、甚至嵌入的 VCS 信息；但它和go version -m同样依赖 build info 存在 - 用
dlv exec mybin启动调试器，在断点里执行print debug.ReadBuildInfo()，可绕过程序是否主动打印的限制；适合无法改源码又必须确认某次 panic 是否由特定依赖引发的场景 - 容易踩的坑：所有基于 build info 的方法，都对
go build -trimpath -ldflags='-s -w'极其敏感——一旦-trimpath开启，main module path可能变成command-line-arguments，导致后续go list完全失焦
复杂点在于：同一个二进制，go version -m 给的是一份“构建快照”，debug.ReadBuildInfo() 给的是另一份“模块解析快照”，而 runtime 实际加载的可能是第三份——三者不一致才是常态，不是 bug。
