Go mod vendor 后构建仍读取 module cache 怎么查

执行过 go mod vendor 后，go build 仍然在日志里出现 module cache，并不一定说明 vendor 失效。先看命令类型：go build、go test 在启用 vendoring 时应从主模块根目录的 vendor 取包；而 go mod tidy、go mod download 和 go get 本来就会解析模块并访问缓存。真正要排查的是当前模块根、-mod 模式、GOFLAGS、go.work 和 vendor/modules.txt。

先确认构建到底站在哪个模块

不要先删除缓存，也不要只凭“输出里出现了缓存目录”下结论。先在实际执行构建的目录运行下面的命令：

# 查看当前模块根、工作区和全局构建参数
go env GOMOD GOWORK GOFLAGS GO111MODULE

# 仅用于确认缓存位置，不代表本次构建一定读取了它
go env GOMODCACHE

GOMOD 应该指向本项目的 go.mod。如果是 /dev/null 或空值，命令可能没有在模块模式下运行；如果 GOWORK 指向一个 go.work，当前入口就可能是工作区，而不是某个子模块。还要检查 GOFLAGS 中是否隐藏着 -mod=mod 或 -mod=readonly。

为什么生成了 vendor 仍可能读 module cache

最常见的原因有四类。第一，vendor 不在主模块根目录，例如项目把它放进了某个子目录；模块模式不会把任意层级的 vendor 当作依赖来源。第二，项目的 go.mod 使用的 go 版本低于 1.14，自动 vendoring 不会开启。第三，命令行或环境变量显式选择了 -mod=mod、-mod=readonly。第四，实际运行的是工作区，子模块里的 vendor 并不是工作区级别的依赖树。

还有一个容易混淆的点：go mod vendor 会根据当前依赖图重建 vendor；它不是“把缓存搬过来后永久锁定”。如果 go.mod 改过、出现新的 replace，或者工作区依赖发生变化，旧的 vendor/modules.txt 就可能与描述不一致。此时正常的构建通常会报 inconsistent vendoring，而不是悄悄使用一份正确的旧目录。

用显式模式定位并修复一致性

先用一次显式模式把判断变成可复现的结果：

# 只要求构建使用主模块根目录的 vendor
go build -mod=vendor ./...

# 查看 vendor 清单中的模块版本和显式依赖标记
sed -n '1,120p' vendor/modules.txt

# 模块模式：按当前 go.mod 和源码重新生成 vendor
go mod vendor

如果显式构建提示缺包或清单不一致，优先确认运行目录和 go.mod 是否是同一棵树，再重新执行 go mod vendor。如果项目确实使用 go.work，应在工作区根目录检查其 use 列表，并用 go work vendor 生成工作区级 vendor，而不是只刷新某个子模块的目录。

为了让 CI 与本地行为一致，可以把模式写进构建命令或任务配置：

# CI 中显式锁定 vendoring，避免继承开发机的 GOFLAGS
GOFLAGS=-mod=vendor go test ./...

# 如果项目不打算提交 vendor，则明确切回模块解析
GOFLAGS=-mod=mod go test ./...

构建命令和模块维护命令不要混为一谈

因此，最小修复顺序是：确认 GOMOD/GOWORK，清点 GOFLAGS，用 go build -mod=vendor ./... 复现，最后按模块或工作区重新生成 vendor。只有这个命令链路稳定后，才有必要进一步分析代理、缓存权限或网络问题。

常见问题

看到 GOMODCACHE 路径就能证明构建读取了缓存吗？

不能。go env GOMODCACHE 只是配置值；要判断来源，应看构建模式并用 -mod=vendor 做对照。

vendor 目录放在仓库根目录就一定会生效吗？

不一定。仓库根目录必须同时是当前主模块根目录；如果实际入口是子模块或工作区，应该以 GOMOD、GOWORK 和对应的 modules.txt 为准。

应该直接删除 module cache 吗？

不建议把删除缓存当作第一步。先确定构建应使用哪种模式；模块维护命令仍需要缓存时，删除它只会把问题变成下载失败。