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 生态中面向确定性交付的一把“保险锁”。用不用看场景，但理解它怎么工作，能帮你避开很多构建漂移问题。
