能用，但必须满足GO111MODULE=off且vendor/目录存在；否则Go工具链忽略vendor转而走module模式，常见失效根源是环境变量未关闭或残留go.mod文件。
Go vendor 模式在老旧项目中还能用吗
能用，但必须满足两个硬性条件：GO111MODULE=off 且项目根目录下 vendor/ 存在；否则 Go 工具链会直接忽略 vendor/，转而走 module 模式。很多“vendor 不生效”的问题，根源其实是环境变量没关——运行 go env GO111MODULE，输出不是 off 就说明 vendor 被绕过了。
Go 1.11+ 默认启用 modules，GO111MODULE=auto 时，只要项目有 go.mod 文件，就会强制走 module 流程，vendor/ 形同虚设。所以老旧项目若没删 go.mod 又没关开关，实际是“假 vendor”状态。
如何验证当前构建真正在用 vendor
光看目录存在没用，得验证 Go 工具链是否真的从 vendor/ 加载依赖：
- 运行
go list -f '{{.Deps}}' . | head -n 5，观察输出路径是否含vendor/前缀（如vendor/github.com/sirupsen/logrus） - 对比
cat vendor/modules.txt | grep logrus，确认该包版本与go list输出一致 - 临时断网后执行
go build -v，若不报cannot find module或网络超时错误，基本可判定走的是本地 vendor
注意：go build 默认不强制走 vendor；必须显式加 -mod=vendor 才可靠。省略该标志，即使有 vendor/ 目录，Go 仍可能从 $GOPATH/pkg/mod 或 proxy 拉取。
立即学习“go语言免费学习笔记（深入）”；
vendor.json 还是 go.mod + go mod vendor
老旧项目如果还在用 govendor 工具和 vendor/vendor.json，说明它属于 pre-Go 1.11 的纯 vendor 体系。这类项目不能混用 go mod：一旦执行 go mod init，就会生成 go.mod，触发 module 模式，原有 vendor.json 失效。
如果项目已迁移到 Go Modules（有 go.mod），那就别碰 vendor.json ——统一用 go mod vendor 管理 vendor/ 内容。此时 vendor/modules.txt 是唯一可信的 vendor 清单，vendor.json 不再被读取。
常见误操作：
- 用
govendor add更新依赖，却忘了同步go.mod→ 构建时版本错乱 - 手动修改
vendor/下某包源码调试，但没跑go mod vendor→ 下次重生成会覆盖你的修改 - 提交
vendor/却漏掉vendor/modules.txt→ CI 构建时-mod=vendor会失败
维护 vendor 最容易被忽略的细节
vendor 目录不是“设好就不用管”的快照，它需要和代码变更保持同步：
- 每次
go get新依赖或升级版本后，必须立刻执行go mod tidy && go mod vendor，否则vendor/和go.mod不一致 -
go mod vendor不会自动清理已删除的依赖；冗余包留在vendor/里可能引发冲突，建议定期配合go mod tidy -v检查 -
vendor/必须提交到 Git —— 但它不是二进制，而是源码副本；禁止对vendor/做 git ignore，否则团队构建必然不一致
真正麻烦的不是生成 vendor，而是当多人协作时，有人忘了 -mod=vendor、有人误删 vendor/modules.txt、有人在 CI 配置里漏写构建参数——这些细节能让 vendor 机制瞬间失效，而且错误表现往往只是随机的编译失败或运行时 panic，很难直接定位到 vendor 上。
