vendor目录解决依赖版本不一致和离线构建问题：它将依赖包特定版本快照到本地，使go build等命令只读取vendor/而非GOPATH或模块缓存，确保构建可重现与离线可用。
vendor目录能解决什么问题
Go 的 vendor 目录本质是把依赖包的特定版本“快照”到项目本地，让 go build、go test 等命令默认只读取它，而非 $GOPATH 或模块缓存。它最直接解决两个现实痛点：
- 团队协作时，不同人
go get到的依赖版本不一致，导致构建结果不可复现 - CI/CD 环境无法联网或只能访问私有镜像，但又需要精确还原开发时的依赖状态
在 Go 1.5 引入 vendor 机制、到 Go 1.11 模块（module）成为默认之前，这是主流的依赖锁定方案。即使现在用 go mod，vendor 仍可作为可选补充——比如你明确要求所有构建必须离线完成。
启用 vendor 后 go 命令的行为变化
只要项目根目录下存在 vendor 文件夹，且当前工作目录在该模块内，go 命令（1.6+）会自动启用 -mod=vendor 模式，即：
-
go build不再读取go.sum或模块缓存，只从vendor/加载包 -
go list -m all仍显示模块依赖树，但go list -f '{{.Dir}}' some/pkg返回的是vendor/下路径 -
go mod tidy默认仍会修改go.mod和go.sum，但不会触碰vendor/内容；要同步 vendor，得显式运行go mod vendor
注意：如果项目启用了 module（有 go.mod），又想临时禁用 vendor，可以加 -mod=readonly 或 -mod=mod 参数覆盖默认行为。
vendor 目录的常见陷阱
看似简单，实操中几个点容易翻车：
- 忘记更新：
go mod vendor不会自动感知go.mod变更，改了依赖后必须手动执行，否则vendor/和go.mod不一致，CI 构建可能失败或行为异常 - 误提交无关内容：
vendor/下可能混入编辑器临时文件、.gitignore 未覆盖的构建产物，导致仓库臃肿甚至泄露敏感信息 - 嵌套 vendor 被忽略：子目录若单独有
go.mod，其vendor/不会被主命令识别；Go 只认当前模块根下的vendor/ -
工具链兼容性差：某些老版本 linter（如
golint）或 IDE 插件（旧版 Goland）在 vendor 模式下路径解析出错，报 “cannot find package”
一个典型错误现象：go test ./... 成功，但 go test -v ./cmd/myapp 报错说找不到某个 vendor 里的内部工具包——这是因为该包被 go.mod 声明为 replace，而 vendor 里没同步替换后的代码。
要不要现在还用 vendor
绝大多数新项目不需要主动维护 vendor 目录。Go 模块 + go.sum 已足够保证可重现构建，而且体积小、更新快、语义清晰。只有当你遇到以下任一情况，才值得引入 vendor：
- 发布二进制前需 100% 离线构建（例如嵌入式设备 CI）
- 公司策略强制要求所有依赖源码必须随项目提交（审计合规）
- 依赖中包含大量 Cgo 文件，且跨平台交叉编译时，模块缓存中的预编译对象与 vendor 中源码行为不一致
如果决定
用，务必把 go mod vendor 加进 CI 流程的前置检查，并在 .gitignore 里严格限定只允许 /vendor/**，禁止 vendor/ 下出现任何非 Go 源码文件。
