Go module vendor 模式下如何确认依赖来自 vendor 目录

项目里已经提交了 vendor 目录，但你仍想确认构建时到底用了哪一份依赖。最可靠的判断不是看目录“在不在”，而是先锁定主模块，再用 -mod=vendor 执行 go list，观察目标包的 .Dir 是否落在主模块顶层 vendor 下，最后用 vendor/modules.txt 对照模块版本。

对单模块项目来说，go list -mod=vendor -f '{{.Dir}}|{{.Module.Path}}|{{.Module.Version}}' 目标导入路径 输出的目录是最直接的取源证据；路径在主模块的 vendor 目录内，才可以确认这次包解析来自 vendor。

先确认命令看到的主模块根目录

先在项目根目录执行检查。这里不要直接把当前目录拼到结果里，因为从子目录运行命令时，Go 仍会向父目录寻找 go.mod；如果存在 go.work，上下文还可能变成工作区。

# 先确认主模块文件和工作区文件，避免把别的项目当成 vendor 根目录
go env GOMOD
go env GOWORK

# 检查 vendor 清单是否存在；清单是 go mod vendor 生成的版本索引
test -f vendor/modules.txt && echo "vendor 清单存在"

# 查看当前模块根目录下的关键入口
ls -ld vendor go.mod vendor/modules.txt

GOMOD 应指向本项目的 go.mod。如果 GOWORK 返回一个工作区文件，先确认这是有意的工作区构建；本文后面的结论以单模块上下文为主。图 1 展示的是主模块顶层 vendor 与依赖包目录的边界，其他模块内部的 vendor 目录不会被当成当前模块的取源目录。

用 -mod=vendor 让验证条件明确

如果项目的 go.mod 使用的 Go 版本允许自动 vendor，go build 或 go test 可能已经采用顶层 vendor；但排查时最好显式写出 -mod=vendor，这样不会把自动选择和环境默认值混在一起。

# 用一个项目确实导入的包替换下面的示例路径
pkg='golang.org/x/text/transform'

# 输出包目录、模块路径和版本；目录是本次取源判断的核心证据
go list -mod=vendor -f '{{.Dir}}|{{.Module.Path}}|{{.Module.Version}}' "$pkg"

# 用同样的 vendor 条件运行测试，确认构建类命令能完成解析
go test -mod=vendor ./...

输出中的 .Dir 如果形如 项目根目录/vendor/golang.org/x/text/transform，说明这次包解析定位到了主模块 vendor。若命令报 inconsistent vendoring，不要先删除目录；它通常说明 go.mod 与 vendor/modules.txt 的版本、显式依赖或 replace 信息没有同步。

把实际路径和 modules.txt 放在一起核对

路径能证明“读了哪里”，但还要确认这份 vendor 内容对应哪个模块版本。go mod vendor 会重建依赖副本，并写入 vendor/modules.txt；因此修改依赖后，重新生成清单是修复动作，不是额外的猜测。

# 只在确认 go.mod 是期望状态后同步 vendor，避免覆盖手工改动
go mod vendor

# 查看目标模块和其包记录；这里的输出是清单文本，不是运行日志
grep -n -A8 -B1 'golang.org/x/text' vendor/modules.txt

# 再次输出实际包目录，确认同步后路径仍落在顶层 vendor
go list -mod=vendor -f '{{.Dir}}|{{.Module.Path}}|{{.Module.Version}}' golang.org/x/text/transform

判断时可按下面的表格分层，不要只看最后一条命令是否退出码为 0：

别用 go mod 命令反推构建取源

这是最容易误判的一层：go mod tidy、go mod download 和 go get 的职责是维护模块图或模块缓存，它们不会因为构建启用了 vendor 就自动变成“只读 vendor”。所以，验证构建取源要看 go list -mod=vendor、go build -mod=vendor 或 go test -mod=vendor 的包目录，而不是看一次 tidy 是否访问过网络。

如果 .Dir 没有落在预期目录，按顺序检查三件事：是否在正确的主模块中、是否存在并使用了顶层 vendor、是否把命令误写成了默认模式或工作区模式。确认 go.mod 依赖已经定稿后，再执行 go mod vendor，最后重复包目录和清单两项核对。

常见问题与边界

go list -m 能不能证明依赖来自 vendor？

不能。它主要展示模块图中的模块信息，不能替代目标包的实际目录检查；要回答取源位置，应查询包的 .Dir。

vendor 目录存在，为什么 go test 仍然提示不一致？

通常是 go.mod 与 vendor/modules.txt 不匹配，或者 replace、显式依赖记录发生变化。先确认依赖改动，再在模块根目录重新执行 go mod vendor。

能不能把依赖模块内部的 vendor 当成当前来源？

不能。模块模式只使用主模块根目录的顶层 vendor；其他模块或子目录里的 vendor 不会替代它。

最后留一条可复用的排查口诀：先看 GOMOD/GOWORK，再用 -mod=vendor 查询目标包 .Dir，随后对照 vendor/modules.txt 的版本记录，最后才处理清单同步。这样得到的是“目录、版本、命令”三项相互印证的结论。