Go 使用 vendor 发布构建时如何确认依赖没有漂移

Go 项目把 vendor/ 提交进发布分支，并不等于依赖已经固定。真正可靠的判断是：重新根据模块图生成 vendor，工作树没有变化，再用 -mod=vendor 编译和测试。这样检查的是同一件事的两面：文件是否同步，以及构建是否真的读取了这份同步后的依赖。

发布前在模块根目录执行 go mod vendor，用 git diff --exit-code 检查 go.mod、go.sum 和 vendor/，随后执行 go build -mod=vendor ./... 与 go test -mod=vendor ./...。其中任何一步有差异或失败，都不要把构建产物视为可发布。

先把 vendor 当成发布输入，而不是缓存目录

go mod vendor 会按照主模块当前的依赖图重建 vendor/，同时生成 vendor/modules.txt，其中记录被复制的模块及版本。依赖升级、删除导入或调整 replace 后，如果只提交了 go.mod 而没有更新 vendor，发布分支就可能出现两套答案。

在仓库根目录先做一次同步检查：

# 在主模块根目录重建提交中的依赖副本
go mod vendor

# 只要任一发布输入被改写，就让 CI 失败
git diff --exit-code -- go.mod go.sum vendor

这条命令不是为了比较文件时间，而是利用 Git 的内容差异。没有输出且退出码为 0，才说明当前模块图重新生成的 vendor 与提交内容一致。

用 vendor/modules.txt 对照 go.mod 判断版本是否漂移

不要只看 vendor/ 是否存在。Go 工具会读取 vendor/modules.txt 中的模块版本，并检查它与 go.mod 是否一致；模块声明变化后，常见结果是构建直接提示需要重新运行 go mod vendor。

需要快速查看构建视角下的模块清单时，可以使用：

# 列出 vendor 模式下 go 命令认识的模块版本
go list -mod=vendor -m all

# 查看清单和 vendor 文件是否还有未提交差异
git diff -- vendor/modules.txt vendor

这里的重点不是把输出复制到另一份人工维护的版本表，而是让 vendor/modules.txt 成为可审查的派生文件。版本漂移时，优先回到产生变化的 go.mod 操作：是升级、降级、删除依赖，还是遗漏了重新生成 vendor。

在干净环境固定为 vendor 构建并验收

文件检查通过后，还要确认实际编译路径没有回到模块缓存或网络代理。发布脚本可以明确指定 vendor 模式：

# 强制构建只从 vendor 读取依赖包
go build -mod=vendor ./...

# 用同一份 vendor 运行所有主模块测试
go test -mod=vendor ./...

在 Go 1.14 及以上，如果主模块的 go.mod 满足条件且 vendor/modules.txt 存在，命令可能自动启用 vendoring；但发布脚本显式写出 -mod=vendor 更容易审查，也不会因为执行机器的默认设置不同而改变含义。

如果仓库同时有 go.work，而发布对象是其中一个独立模块，可以在确认业务确实不依赖工作区组合后使用 GOWORK=off，并从该模块根目录执行上述命令。不要为了让命令“通过”而盲目关闭工作区；工作区本身可能就是发布输入的一部分。

三个容易把依赖漂移判断错的情况

只提交 vendor 目录就够了吗？

不够。go.mod 与 vendor/modules.txt 的版本关系也必须一致；最简单的门禁仍然是重建后检查 Git 差异。

为什么本地能编译，发布机却失败？

本地缓存可能提供了 vendor 之外的包。用 -mod=vendor 固定读取来源后，缺失或过期的 vendor 会尽早暴露。

go mod tidy 会不会也只使用 vendor？

不会。模块维护命令仍可能访问模块缓存或网络；发布验收要把“更新依赖”和“使用已提交依赖构建”分成两个阶段。

因此，发布门禁可以记成一条短链路：同步模块图，检查工作树，固定 vendor 构建，再把异常回溯到具体的依赖变更。只要这四个判断使用同一模块根目录，vendor 就不只是仓库里的副本，而是可复查的发布输入。