Go go list -m all 显示的版本和构建不一致怎么办

我遇到过一种很容易误判的构建问题：go list -m all 显示的是某个版本，实际构建日志或二进制里的依赖却像是另一个版本。多数时候不是 Go 随机选了依赖，而是比较了不同层的输入。go list -m all 关注模块构建列表，真正参与某个目标编译的包还会受到目标包、构建标签、GOOS/GOARCH、go.work 和 vendor 模式影响。

官方资料：https://go.dev/ref/mod

先把检查对象统一：模块版本用 go list -m -json all，实际包用与构建相同条件的 go list -deps，最终产物再用 go version -m。三者对不上时，优先查模式、替换目录和工作区。

先把“版本不一致”拆成三种输入

我通常先记住三个问题：模块图选了什么版本，目标包真正导入了哪些包，最后一次构建到底使用了哪套环境。go list -m all 输出的是模块构建列表，能看到主模块、依赖模块和替换关系；它不是“当前二进制中每个编译包的清单”。Go 官方文档也把 build list 定义为构建使用的模块版本集合。

因此，第一步不要只打开 go.mod 猜版本，先把环境写下来：

# 中文注释：记录工作区、模块文件和全局构建参数，避免在不同目录比较结果
go env GOMOD GOWORK GOFLAGS GOOS GOARCH GOPROXY

# 中文注释：查看模块构建列表及 replace 后的目录、版本和校验和
go list -m -json all

为什么 go.mod、vendor 和列表会不同

go.mod 写的是模块要求，最终版本还要经过最小版本选择；replace 可以把某个版本指向本地目录，所以列表里的版本字段和源码实际位置可能同时出现。若项目有 go.work，命令又可能处在工作区上下文，当前目录并不等于单一模块根目录。

vendor 也要单独看。Go 1.14 及以上在 vendor/modules.txt 与 go.mod 一致时可能自动使用 vendor；显式 -mod=vendor 则把顶层 vendor 作为依赖来源。此模式不能用 go list -m all 计算完整模块图，官方测试脚本明确建议改用 -mod=mod 或 -mod=readonly 查询模块图。

# 中文注释：查看 vendor 记录的版本和显式模块，不修改 go.mod
sed -n '1,80p' vendor/modules.txt
go list -mod=vendor -f '{{with .Module}}{{.Path}} {{.Version}} {{.Dir}}{{end}}' ./...

# 中文注释：需要完整模块图时切回模块模式，readonly 防止命令改写文件
go list -mod=readonly -m -json all

如果同一个依赖在两处出现不同版本，先检查 go env GOFLAGS 是否暗含 -mod=vendor，再确认是否从项目根目录执行；不要先删除 go.sum 或盲目运行 go get -u。

用同一套构建条件核对真正的包依赖

模块列表回答“可用的模块版本是什么”，包列表才更接近“这个目标会编译哪些包”。查询时必须复刻构建命令的目标、标签、操作系统和架构，否则你比较的仍是两次不同构建。

# 中文注释：把目标、标签和模式写死，输出目标包实际依赖的模块版本
GOOS=linux GOARCH=amd64 go list -mod=mod -tags='prod' -deps -f '{{with .Module}}{{.Path}} {{.Version}}{{end}}' ./cmd/server

# 中文注释：若正式构建使用 vendor，就保持同一模式再查包目录
GOOS=linux GOARCH=amd64 go list -mod=vendor -tags='prod' -deps -f '{{.ImportPath}} {{with .Module}}{{.Path}}@{{.Version}}{{end}} {{.Dir}}' ./cmd/server

这里看到的目录尤其有用：路径落在项目的 vendor/ 下，说明包输入来自 vendor；路径落在模块缓存或 replace 目录，则应继续对照 go list -m -json 的 Replace 字段。若两个命令的版本不同，先解决构建模式不同，再讨论依赖升级。

最后用二进制 BuildInfo 收口

如果问题来自已经发布的二进制，重新看当前目录的模块列表还不够。构建完成后，使用和发布产物相同的文件检查内嵌的模块信息：

# 中文注释：读取二进制写入的 Go 版本、主模块和依赖模块信息
go version -m ./dist/server

# 中文注释：只抽取依赖行，便于和 go list -m -json all 的版本逐项比较
go version -m ./dist/server | grep -E '^[[:space:]]+(path|mod|dep|build)[[:space:]]'

收口时按这个顺序判断：path 是哪个主模块，mod 是产物声明，dep 是产物记录的依赖，build 则提示构建环境。若 BuildInfo 与当前列表不同，常见原因是检查了旧二进制、CI 使用了另一份 go.work，或者构建机带有不同的 GOFLAGS 和 vendor 状态。

修复后保留一份可复查的清单

团队协作时，建议把构建目录、目标、标签、模式和工具链一起写进 CI 日志；需要 vendor 就在依赖变更后重新执行 go mod vendor，不需要 vendor 则明确使用 -mod=mod 或 -mod=readonly。不要把 go list -m all 当作万能版本证明，它只是模块层证据。

最小复查可以保存三份输出：模块层的 go list -m -json all，包层的 go list -deps，产物层的 go version -m。三份输出使用同一个提交、目录、模式和构建条件，版本差异才有可比性。

常见追问

为什么 go list -m all 里有模块，但二进制里看不到？

模块构建列表包含可供构建使用的模块版本，目标包可能没有导入其中的包；构建标签和平台也会改变实际包集合。用与正式构建一致的 go list -deps 对照，而不是按模块列表逐项猜测。

vendor 下能不能直接用 go list -m all？

不要把它当作完整模块图命令。vendor 目录只保留满足当前主模块构建和测试所需的内容，官方工具测试说明在 vendor 模式下计算 all 会失败；需要模块图时使用 -mod=mod 或 -mod=readonly，需要检查包来源时再用 -mod=vendor。