Go 的 vendor 目录是项目依赖的“本地快照”，将第三方包按精确版本复制进项目，确保构建不依赖网络、版本可控且隔离；go mod vendor 生成 vendor/ 和 modules.txt，go build 默认优先使用 vendor，需提交到 Git 以保障构建一致性。
Go 的 vendor 目录本质是项目依赖的“本地快照”，它把所有用到的第三方包按精确版本原样复制进项目里，让构建不再依赖网络或远程仓库，确保每次编译都用同一套代码。
Go 编译器默认优先从项目根目录下的 vendor/ 查找导入的包，找不到才退回到 GOPATH 或模块缓存。这意味着：
r 生成 vendor/ 和 modules.txt，go build 默认优先使用 vendor，需提交到 Git 以保障构建一致性。go mod download
执行 go mod vendor 时，Go 工具链会：
go.mod 中声明的依赖及其版本，再对照 go.sum 校验完整性vendor/ 目录vendor/modules.txt，记录包路径、版本、校验和，作为 vendor 内容的“清单”只要项目存在 vendor/ 目录，go build、go test 等命令默认就走 vendor 路径。你也可以显式确认：
go build -mod=vendor —— 强制只从 vendor 加载依赖（推荐用于 CI）go list -mod=vendor -f '{{.Dir}}' . 可验证当前是否在 vendor 模式下解析-mod=readonly 或 -mod=mod
需要，但得注意方式：
git add vendor 并提交，否则新协作者 clone 后无法直接构建.gitignore 里没有 vendor/ 这一行go get 或改 go.mod，再 go mod vendor，最后提交 vendor 和 go.mod/go.sum基本上就这些。vendor 不是过时的补丁，而是 Go Modules 生态中面向确定*付的一把“保险锁”。用不用看场景，但理解它怎么工作，能帮你避开很多构建漂移问题。