vendor目录是go项目的依赖快照，编译时优先从./vendor查找包以确保构建可重现、离线可用、版本不漂移；该机制自Go 1.6默认启用，现代Go（1.14+）自动识别vendor路径。
vendor 目录就是项目自己的“依赖快照”——Go 编译时优先从 ./vendor 里找包，而不是远程或 $GOPATH，从而实现构建可重现、离线可用、版本不漂移。
为什么 Go 会优先用 vendor 目录里的包？
这是 Go 工具链内建的查找顺序规则：当代码 import github.com/gin-gonic/gin 时，Go 会按以下顺序定位该包：
- 当前包所在目录的
vendor/子目录（如./vendor/github.com/gin-gonic/gin） - 逐级向上查找父目录中的
vendor/（但实践中只应有且仅有一个顶层vendor） - 再 fallback 到
$GOPATH/src/（Go 1.11+ 默认已弱化此路径） - 最后是
$GOROOT/src/（标准库）
这个机制从 Go 1.6 起默认开启，无需设 GO15VENDOREXPERIMENT=1；现代 Go（1.14+）完全自动识别，只要 vendor/ 存在，go build 就会静默走 vendor 路径。
什么时候必须生成并提交 vendor 目录？
不是所有项目都需要，但以下场景中忽略 vendor 很可能出问题：
立即学习“go语言免费学习笔记（深入）”；
- CI/CD 流水线要求离线构建：docker 构建镜像时网络受限，
go build -mod=vendor才能稳定通过 - 生产部署环境无法访问公网：比如金融、军工类内网集群，依赖必须提前“打包进代码”
- 团队多人协作且对构建一致性有强要求：避免某人本地
go get拉了新版本导致编译通过但行为异常 - 审计/合规需要锁定第三方源码：vendor 内容可纳入代码扫描、SBOM 生成、许可证检查
注意：go mod vendor 生成的 vendor/ 必须和 go.mod、go.sum 一起提交 Git——否则别人 clone 后执行 go build 仍会尝试联网拉取。
常见错误：vendor 目录存在但没生效？
现象：明明有 ./vendor，运行 go build 却报错说找不到包，或日志显示仍在下载 golang.org/x/net 等模块。
原因和修复建议：
- 项目不在模块模式下：没有
go.mod文件 → 先运行go mod init myproject - go.mod 中依赖未 clean：有冗余或 unreachable 的
require→ 运行go mod tidy再go mod vendor - 误用了旧版 Go 或环境变量干扰：比如设置了
GOFLAGS="-mod=readonly"→ 检查go env GOFLAGS，临时清空再试 - vendor 目录结构被手动修改过：比如删了某个子目录但没更新
modules.txt→ 直接删掉整个vendor/，重新go mod vendor
验证是否生效最简单的方法：
go list -f '{{.Dir}}' github.com/gin-gonic/gin 如果输出路径包含 ./vendor/，说明走的是本地副本；若指向 $GOPATH/pkg/mod/ 或报错，则 vendor 未被采用。
vendor 不是银弹：体积大、更新成本高、类型隔离副作用
把所有依赖源码塞进项目，会带来几个现实代价：
-
vendor/动辄 20–50 MB，大幅拖慢git clone和 ide 索引速度 - 升级一个依赖需重新
go mod tidy && go mod vendor，且要人工确认vendor/modules.txt变更是否合理 - 若项目同时作为库（被其他项目 import）又自带
vendor，调用方可能因类型不兼容报错：cannot use x (type "myproj/vendor/github.com/some/lib".Client) as type "github.com/some/lib".Client
所以，除非明确需要离线构建或强一致性保障，现代 Go 项目更推荐以 go.mod 为唯一真相源，vendor 仅作为特定环境的“构建兜底手段”。它不是用来替代 Modules 的，而是 Modules 的一个可选加固层。