Go vendor 目录存在但构建仍访问代理是什么原因

Go 项目虽然有 vendor 目录，构建仍访问代理，通常不是代理配置本身的问题，而是当前命令没有使用 vendor 模式。最常见的原因有四个：vendor 不在主模块根目录、go.mod 的 go 版本低于 1.14、命令其实是 go mod tidy 或 go mod download，以及工作区或 -modfile 让命令使用了另一套模块视图。

官方文档：https://go.dev/ref/mod

先记住一个边界：go build、go test 等构建命令可以从主模块顶层 vendor 读依赖；go mod vendor、go mod tidy、go mod download 和 go get 仍然是模块管理动作，可能访问代理或版本库。

先确认当前命令有没有机会使用 vendor

Go 只认主模块根目录下名为 vendor 的目录。模块模式下，如果 go.mod 中的 go 指令为 1.14 或更高，构建命令在存在该目录时默认相当于 -mod=vendor；更稳妥的排查方式仍是显式查看根目录和 Go 环境。

# 在项目根目录执行，避免把子目录误当成主模块
pwd
go env GOMOD GOWORK GOPROXY GOFLAGS

# 确认 vendor 和清单都属于当前主模块
test -f go.mod && test -d vendor && test -f vendor/modules.txt

# 查看 go.mod 的模块版本声明；它影响默认 vendor 行为
sed -n '/^go /p' go.mod

如果 GOMOD 指向的不是你正在查看的 go.mod，先切回主模块根目录。若 GOWORK 指向 go.work，当前命令还可能处在 workspace 视图中；此时只看单模块的 vendor 目录容易得出错误结论。

用 -mod=vendor 固定真正的构建路径

如果目标是让编译或测试不通过代理取包，直接给构建命令加 -mod=vendor，不要只设置 GOPROXY。在这个模式下，构建命令从 vendor 读取依赖；如果 vendor 与 go.mod 的模块版本不一致，命令会报错，应该重新生成清单，而不是退回代理。

# 显式要求编译从主模块 vendor 读取依赖
go build -mod=vendor ./...

# 测试也使用同一模块模式
go test -mod=vendor ./...

# 只在确实需要离线构建时临时禁止网络，便于暴露漏进 vendor 的依赖
GOPROXY=off go test -mod=vendor ./...

最后一条命令是排错手段，不是用来修复清单的命令。如果它提示某个包不在 vendor 中，先确认这个包是否应该由当前模块构建，再用 go mod vendor 更新目录。go mod vendor 本身需要解析模块依赖，所以不要把它和离线构建混为一谈。

为什么有 vendor 仍然看到代理请求

看到代理日志时，先看执行的子命令，而不是先删除缓存。下面几类行为本来就不等价：

另外，GOFLAGS=-mod=mod 会覆盖你对默认行为的预期；显式的命令行参数应放在排查时优先确认。使用 -modfile 时，命令仍要求模块根目录存在名为 go.mod 的文件来识别根目录，但依赖声明可能来自另一份 mod 文件，因此对应的 vendor 不能简单复用。

modules.txt、workspace 和代理的三个边界

• 清单边界：vendor/modules.txt 记录 vendored 模块版本。它与 go.mod 不一致时，应重新运行 go mod vendor。
• workspace 边界：当前命令若由 go.work 组合多个模块，单个模块下的 vendor 不代表整个工作区都已准备完毕；需要明确 workspace 的依赖视图。
• 命令边界：构建阶段离线，不等于依赖维护阶段离线。把 GOPROXY=off 放在 go mod tidy 上，得到的是无法补齐模块的错误，而不是 vendor 生效证明。

因此，最短排查顺序是：确认 GOMOD 和 GOWORK，检查顶层 vendor/modules.txt，用 -mod=vendor 重跑实际的 build/test，最后再判断代理请求是否来自独立的模块管理命令。这样可以把“vendor 没生效”和“这条命令本来就会访问模块源”分开。

结论与延伸问题

vendor 目录不是全局网络开关。要让构建不访问代理，应让命令落在正确的主模块根目录，确认 go.mod、vendor/modules.txt 与工作区视图一致，并用 -mod=vendor 明确指定构建模式；如果执行的是 go mod tidy、go mod download 或 go get，看到代理访问属于另一条模块管理路径。

只设置 GOPROXY=off 能证明 vendor 生效吗？不能，它只能阻止网络下载；应结合 -mod=vendor 和当前命令类型判断。

为什么 vendor 在子模块目录里却没被使用？模块模式只使用主模块根目录下的 vendor，其他模块或子目录的 vendor 不会自动成为当前构建来源。

modules.txt 过期要不要手工修改？不建议手工改，应该根据当前 go.mod 和源码重新运行 go mod vendor。