vendor是项目本地的依赖代码副本，用于离线构建和强依赖锁定；go.mod声明版本，vendor存放实际代码，二者分工明确：前者管“用哪个版本”，后者管“代码放这儿”。
Go 的 vendor 机制本质是把依赖代码“复制一份”到项目本地，实现构建可重现、不依赖外部模块代理或网络。从 Go 1.5 引入 vendor，到 Go 1.11 后被 go mod 取代为主流，但 vendor 仍在某些场景下实用——比如离线环境、强依赖锁定、CI/CD 构建一致性等。
vendor 是什么，和 go.mod 有什么区别？
vendor 目录是项目根目录下的 ./vendor 文件夹，里面存放了当前项目直接/间接依赖的所有第三方包源码（含版本信息）。它不依赖 GOPATH，也不需要模块代理，go build / go test 默认会优先读取 vendor 中的包（只要 vendor 存在且 go version ≥ 1.6）。
而 go.mod 是 Go Modules 的声明式依赖清单，记录的是模块路径+版本号，实际代码仍从 $GOPATH/pkg/mod 或 proxy 下载缓存；vendor 只是 go mod vendor 命令生成的“快照副本”，本身不参与版本解析。
简单说：go.mod 管“该用哪个版本”，vendor 管“代码就放这儿，别去网上找”。
立即学习“go语言免费学习笔记（深入）”；
如何生成和更新 vendor 目录
确保项目已启用 Go Modules（有 go.mod 文件），然后运行：
- go mod vendor：将 go.mod 中所有依赖（含 transitive）复制到 ./vendor，同时生成 vendor/modules.txt 记录精确版本来源
- go mod vendor -v：显示详细复制过程，方便排查缺失或冲突
- go mod tidy && go mod vendor：先清理冗余依赖、补全缺失项，再生成 vendor —— 这是推荐的一体化流程
注意：vendor 不会自动更新。如果改了 go.mod（如升级某依赖），必须重新执行 go mod vendor 才能同步代码。
常见 vendor 使用场景与注意事项
离线构建：把 vendor 目录连同源码一起提交 Git，CI 机器无需配置 GOPROXY 或联网，直接 go build 即可编译。
依赖锁定更“硬”：相比 go.sum 只校验哈希，vendor 是完整代码快照，避免因上游删库、tag 被 force push 导致构建失败。
需注意的坑：
- vendor 目录体积大，频繁提交易拖慢 Git；建议 .gitignore 中排除 vendor/（除非你明确要求强制包含）
- go test -mod=vendor 可显式启用 vendor 模式，但默认已生效；若测试失败，先确认是否误用了 go run 或未清理旧缓存
- 某些工具（如 gopls、gofmt）可能忽略 vendor 行为，IDE 提示错误但实际构建正常——这是预期行为，不必强求编辑器完全对齐 vendor
vendor 和 go.work、多模块项目怎么共存？
go.work 用于管理多个 modules 工作区，它本身不感知 vendor。每个 module 仍可独立运行 go mod vendor，生成各自的 vendor 目录（通常放在各自根目录下）。
不建议跨 module 共享一个 vendor；也不推荐在 go.work 根目录放 vendor——go build 不会自动向上查找 vendor，它只认当前 module 根下的 ./vendor。
若多个 module 共用同一组依赖，更合理的方式是：统一升级 go.mod → 分别 go mod vendor → 提交各自 vendor，而非手动合并或符号链接。
基本上就这些。vendor 不复杂但容易忽略细节，关键是理解它“只是副本，不是源头”。用好它，能让你的构建链路更可控、更透明。
