Go vendor目录作用及工作机制解析

Go 的 vendor 目录是项目依赖的“本地快照”，将第三方包按精确版本复制进项目，确保构建不依赖网络、版本可控且隔离；go mod vendor 生成 vendor/ 和 modules.txt，go build 默认优先使用 vendor，需提交到 Git 以保障构建一致性。

Go 的 vendor 目录本质是项目依赖的“本地快照”，它把所有用到的第三方包按精确版本原样复制进项目里，让构建不再依赖网络或远程仓库，确保每次编译都用同一套代码。

vendor 让依赖完全可控

Go 编译器默认优先从项目根目录下的 vendor/ 查找导入的包，找不到才退回到 GOPATH 或模块缓存。这意味着：

• 团队成员拉下代码就能直接构建，无需额外 go mod download
• CI/CD 流水线在离线或受限网络环境也能稳定运行
• 即使某个 GitHub 仓库被删、tag 被强制覆盖，你的 vendor 里仍保留着当时可用的代码
• 不同项目可共存互不干扰——A 项目用 logrus v1.8，B 项目用 v1.9，各自 vendor 隔离

go mod vendor 做了什么

执行 go mod vendor 时，Go 工具链会：

• 读取 go.mod 中声明的依赖及其版本，再对照 go.sum 校验完整性
• 把每个依赖包的全部源码（含子模块）完整复制进 vendor/ 目录
• 生成 vendor/modules.txt，记录包路径、版本、校验和，作为 vendor 内容的“清单”
• 自动忽略未被代码实际 import 的间接依赖（除非显式 require）

构建时如何启用 vendor

只要项目存在 vendor/ 目录，go build、go test 等命令默认就走 vendor 路径。你也可以显式确认：

• go build -mod=vendor —— 强制只从 vendor 加载依赖（推荐用于 CI）
• go list -mod=vendor -f '{{.Dir}}' . 可验证当前是否在 vendor 模式下解析
• 若想临时禁用 vendor，可加 -mod=readonly 或 -mod=mod

要不要提交 vendor 到 Git

需要，但得注意方式：

• 必须 git add vendor 并提交，否则新协作者 clone 后无法直接构建
• 确保 .gitignore 里没有 vendor/ 这一行
• vendor 体积大是事实，但 Git 对重复文件有压缩，实际增量并不夸张
• 更新依赖后，先 go get 或改 go.mod，再 go mod vendor，最后提交 vendor 和 go.mod/go.sum

基本上就这些。vendor 不是过时的补丁，而是 Go Modules 生态中面向确定性交付的一把“保险锁”。用不用看场景，但理解它怎么工作，能帮你避开很多构建漂移问题。