vendor目录本质是依赖快照，仅在GO111MODULE=on且显式指定-mod=vendor时生效；需用go mod vendor生成并手动清理冗余，其内容须与go.sum一致，否则构建失败。
Go 语言的 vendor 目录本质是依赖“快照”，不是“镜像”或“缓存”——它只在 go build、go test 等命令启用 vendor 模式时才被读取，且优先级高于 GOPATH 和模块代理。
什么时候 vendor 目录才真正生效
从 Go 1.14 开始，vendor 默认仅在项目根目录存在 go.mod 且设置了 go 1.14+ 版本，并显式启用 -mod=vendor 时才起作用。不加这个 flag，即使有 vendor 目录，go build 仍会走模块下载流程。
-
go build -mod=vendor：强制只用 vendor，找不到包直接报错cannot find module providing package xxx -
go list -mod=vendor ./...：检查 vendor 是否覆盖全部依赖 - CI/CD 中务必显式加
-mod=vendor，否则本地能过、流水线失败很常见 -
GO111MODULE=on是前提，off模式下 vendor 被完全忽略
如何生成和更新 vendor 目录
用 go mod vendor 生成 vendor 目录，但它不会自动清理未引用的包——vendor 里可能残留已删掉的依赖，导致误用或安全风险。
- 首次生成：
go mod vendor（要求当前目录有go.mod） - 同步变更：
go mod vendor -v查看哪些包被复制/跳过 - 清理冗余：
go mod vendor不会删旧包，需手动rm -rf vendor/xxx/oldpkg或用第三方工具如go-mod-vendor-clean - 注意
replace指令：如果go.mod里有replace example.com/a => ./local/a，go mod vendor会把./local/a复制进去，而非原远程路径
vendor 目录下为什么有些包没被拉进来
vendor 只包含「构建时实际需要」的包，不是 go.mod 里所有 require 的包都进 vendor。比如某个依赖只在 _test.go 中 import，而你运行的是 go build（非 go test），它就不会被 vendor 收录。
立即学习“go语言免费学习笔记（深入）”；
- 验证是否全量：
go list -f '{{.Dir}}' all | grep '^vendor/' | wc -l对比go list all | wc -l - 测试专用依赖（如
gotest.tools/v3）默认不进 vendor，除非你执行go test -mod=vendor -
//go:build ignore或条件编译标签影响的包，可能被跳过 - 私有仓库未配置
GOPRIVATE时，go mod vendor会失败，不是静默跳过
vendor 和 go.sum 冲突怎么办
vendor 目录内容与 go.sum 不一致时，go build -mod=vendor 仍会校验 go.sum —— 它不是摆设。如果 vendor 里的代码被手动改过，或 go.sum 被清空，构建会失败并提示 checksum mismatch。
- 修复方式：删掉
vendor和go.sum，重新go mod tidy && go mod vendor - 不要手动编辑 vendor 里的文件；如需 patch，应使用
go mod edit -replace+go mod vendor - CI 中建议加一步校验：
go mod verify，确保 vendor + go.sum + go.mod 三者自洽
vendor 不是银弹，它让构建可重现，但也锁死了依赖版本粒度——连间接依赖的小版本升级都要重新 vendor。真正难处理的，往往是那些没进 vendor 却又在运行时动态加载的包，比如通过 plugin.Open 或 driver.Open 加载的驱动，它们的依赖不会出现在 all 列表里，也自然不会进 vendor。
