vendor目录是Go模块启用前的依赖快照机制，通过将第三方包复制到本地vendor/子目录实现构建可重现；go mod vendor按go.mod+go.sum生成快照，但不处理replace本地路径模块。
vendor目录是Go模块启用前的依赖快照机制
Go 1.5 引入 vendor 目录，本质是把当前项目依赖的第三方包**复制一份到本地 vendor/ 子目录中**，让 go build、go test 等命令默认优先从这里加载，从而实现构建可重现、不依赖外部网络或远程仓库状态。它不是包管理器，也不解决版本冲突——只是“锁定”某一时刻的依赖树快照。
手动维护 vendor 目录的典型流程
在 Go 1.11+ 默认启用 Go modules 的背景下，vendor 仍被广泛用于 CI 构建或离线环境。要生成或更新它，必须显式启用 vendor 模式：
- 确保项目根目录下有
go.mod（用go mod init初始化） - 运行
go mod vendor—— 这会清空现有vendor/并按go.mod+go.sum复制所有直接/间接依赖 - 后续
go build会自动使用vendor/，无需额外参数（除非你禁用了 vendor 模式） - 若想临时跳过 vendor 使用远程模块，加
-mod=readonly或-mod=mod
注意：go mod vendor 不会拉取 replace 指向本地路径的模块（比如 replace example.com/a => ./local/a），它们不会被复制进 vendor/，构建时仍需本地存在。
常见 vendor 相关错误和规避方式
最典型的失败场景是构建时提示找不到包，或 panic 报错说某个函数不存在——这往往是因为 vendor/ 和 go.mod 不一致，或误删了部分子目录：
cannot find package "xxx" in any of...：检查vendor/xxx/是否真实存在，且路径拼写与 import 语句完全一致（大小写敏感）- 升级某个依赖后
go mod vendor没生效：先运行go get -u xxx@v1.2.3更新go.mod，再执行go mod vendor vendor/modules.txt is out of sync：这是旧版 Go（<1.14）的遗留文件，新版已弃用；删除它，只信任go.mod和go.sum- CI 中 vendor 构建失败：确认 CI 环境未设置
GOPROXY=off或GO111MODULE=off，否则go mod vendor可能静默失败
vendor 与 go.work、多模块项目的兼容性
如果你的代码库包含多个 go.mod（例如微服务集合），vendor 是按单个 module 生效的。每个子模块需独立运行 go mod vendor，且不能跨 module 共享一个 vendor 目录。
go.work 文件（Go 1.18+）用于多模块工作区协调，但它**不改变 vendor 行为**：每个 workspace 内的 module 仍各自维护自己的 vendor/。强行把多个 module 的依赖塞进同一个 vendor 目录会导致 go build 找不到包或版本混乱。
go work use ./service-a ./service-b # service-a/vendor/ 和 service-b/vendor/ 必须分开存在
真正容易被忽略的是：vendor 目录一旦生成，就完全脱离 GOPROXY 和 GOSUMDB 的校验链——它只依赖本地文件完整性。这意味着你得自己确保 go mod vendor 执行时网络可信、源包未被篡改，否则快照本身就有风险。
