Go vendor 后编译仍下载模块怎么办

项目明明提交了 vendor，执行 go build 或 go test 时却还能看到模块代理请求，最常见的原因不是“Go 不认识 vendor”，而是当前命令根本没有采用它。先看是否存在 -mod=mod 或 GOFLAGS=-mod=mod，再确认 go.mod 的 go 指令、顶层目录位置和 vendor/modules.txt 是否匹配。

最快的修复路径是：在主模块根目录执行 go env GOFLAGS GOMOD GOVERSION，用 go build -mod=vendor ./... 做一次显式验证；如果提示 vendoring 不一致，就执行 go mod vendor，并把更新后的 vendor/ 和 vendor/modules.txt 一起提交。

先确认到底是谁让 Go 下载模块

先在包含 go.mod 的目录执行下面的检查。这里不修改项目，只把有效配置和模块根目录打印出来。

# 查看模块根目录、工具链版本和可能覆盖模式的环境变量
go env GOMOD GOVERSION GOFLAGS

# 用显式 vendor 模式观察是否仍然需要解析远程模块
go build -mod=vendor ./...

如果 GOFLAGS 输出了 -mod=mod，它会影响没有显式 -mod 参数的构建命令；CI 中还要检查工作流文件、镜像环境和脚本是否重新设置了它。可以先用 GOFLAGS= go build -mod=vendor ./... 做隔离测试。若显式 vendor 能通过，而普通命令仍下载，问题就在默认模式或环境注入，而不在依赖内容。

自动 vendor 有版本和目录前提

Go 官方从 1.14 开始支持一种默认行为：主模块存在顶层 vendor 目录，且 go.mod 中的 go 指令不低于 1.14 时，接受 -mod 的构建类命令可以默认使用 vendor。这个行为只针对主模块根目录下的顶层 vendor，把目录放在子模块、工作目录外或只在某个父目录保留，都不能替代它。

先确认两件事：命令运行位置确实属于目标模块；go.mod 没有被 CI 中另一份文件或 go.work 选中。go env GOMOD 输出的路径是判断依据。若项目使用 workspace，还要确认实际参与构建的模块集合与生成 vendor 的范围一致。

vendor 目录有文件，不等于它是可用的依赖快照

go mod vendor 会根据主模块当前的 go.mod、源码导入和测试依赖重建目录，同时生成 vendor/modules.txt。手工删除一个包、只拷贝源码，或修改了 replace 后没有重建，都可能让这个清单与模块声明失配。典型报错会指出某个模块在 go.mod 中被显式要求、替换或标记方式不同。

# 先保存当前模块文件，再按当前依赖关系重建 vendor 快照
cp go.mod /tmp/go.mod.before-vendor
cp go.sum /tmp/go.sum.before-vendor 2>/dev/null || true

# 让 Go 重新生成 vendor/ 和 vendor/modules.txt
go mod vendor

# 用本地快照完成一次构建，避免把“目录存在”误当成“目录可用”
go build -mod=vendor ./...

如果项目有本地 replace，重点看 vendor/modules.txt 是否记录了同一个替换目标；如果使用较新的 Go 工具链，清单中还可能包含模块的显式依赖或最低 Go 版本信息。不要为了消除错误直接删除 go.mod 中的依赖声明，那会把问题藏起来。

把本地验证结果和 CI 构建入口对齐

本地通过而 CI 仍下载，通常是构建入口不一致。建议把模式写在构建命令里，让日志和脚本都能看懂依赖来源：

# CI 明确使用仓库内的 vendor，失败时保留原始诊断信息
set -e
GOFLAGS= go test -mod=vendor ./...
GOFLAGS= go build -mod=vendor -o ./bin/service ./cmd/service

如果团队确实希望使用模块代理，就不要把 vendor 当成离线保证；统一使用 -mod=mod，并把代理、校验和网络权限纳入构建条件。两种模式不能靠“目录是否存在”猜测，应该由脚本明确选择。无论选择哪一种，都要固定 Go 工具链版本，并在依赖变更后重新执行 go mod vendor。

常见问题

为什么 go build -mod=vendor 比普通 go build 更可靠？

它直接表达了依赖来源，绕开默认模式推断；如果快照不完整，会立即暴露清单或包缺失问题。

清空 GOMODCACHE 能解决 vendor 下载吗？

不能。清空缓存只会让模块解析更容易失败；只有命令实际采用 vendor，才不会把缓存作为依赖来源。

修改依赖后必须手工编辑 vendor/modules.txt 吗？

不建议。让 go mod vendor 根据当前模块声明重建，手工编辑容易留下版本、replace 或显式标记不一致。

官方资料入口：https://go.dev/ref/mod#vendoring、https://go.dev/doc/go1.14。遇到“仍在下载”时，按“有效参数 → 模块根目录 → go 指令版本 → vendor 清单 → CI 入口”的顺序检查，通常能在一次显式构建中确定责任边界。