本文系统讲解 go 1.6 起默认启用的 vendor 机制原理、正确使用方式及常见陷阱，涵盖目录结构要求、构建命令规范、版本兼容性判断与现代 go modules 下的 vendor 兼容策略。
本文系统讲解 go 1.6 起默认启用的 vendor 机制原理、正确使用方式及常见陷阱，涵盖目录结构要求、构建命令规范、版本兼容性判断与现代 go modules 下的 vendor 兼容策略。
Go 的 vendor 机制是官方为解决依赖版本漂移与构建不可重现问题而设计的关键特性。自 Go 1.5 实验性引入（需设置 GO15VENDOREXPERIMENT=1），至 Go 1.6 起完全默认启用：只要项目根目录下存在 vendor/ 子目录，go build、go test、go run 等命令便会自动优先从 vendor/ 中解析导入路径，仅当未命中时才回退至 $GOPATH/src。该行为完全由目录结构驱动，无需额外配置或环境变量。
但必须强调一个核心前提：vendor/ 目录必须位于 $GOPATH/src 下的有效包路径中。这是初学者最容易踩坑的地方——如问题中所示，将项目直接放在 ./src/（非 $GOPATH/src/xxx）下，即使结构完整，Go 工具链也无法识别其为合法包，导致 vendor 完全失效。
✅ 正确项目结构应如下（以 myapp 为例）：
$GOPATH/
└── src/
└── myapp/ # ← 必须是 $GOPATH/src 下的子目录
├── main.go
└── vendor/
└── github.com/
└── zenazn/
└── goji/ # ← 完整源码，含 .go 文件
随后执行：
# 进入项目根目录（即 myapp/） cd $GOPATH/src/myapp # 构建（自动启用 vendor） go build -o myapp . # 或安装到 $GOPATH/bin go install myapp
⚠️ 注意事项：
- go run ./src/main.go 类似路径式调用会绕过 vendor 机制，因 Go 将其视为“临时文件编译”，不按包路径解析依赖；
- go get 绝不会填充或更新 vendor/，它始终作用于 $GOPATH/src；vendor 目录必须手动维护或借助工具（如 govendor、godep、gvt）生成；
- Go 1.11+ 默认启用模块（GO111MODULE=on），此时传统 vendor 模式被弱化：若项目含 go.mod，需显式设置 GO111MODULE=off 才能激活旧式 vendor 查找逻辑；
- 更推荐的现代方案是使用 go mod vendor（需先 go mod init）：它基于 go.mod 自动生成包含完整依赖树（含间接依赖）和校验文件 vendor/modules.txt 的 vendor 目录，并需配合 -mod=vendor 参数构建：
go mod init myapp go mod tidy go mod vendor # 生成标准化 vendor/ go build -mod=vendor . # 显式启用 vendor 模式
? 关键验证技巧：运行 go build -v，若输出中出现 vendor/github.com/zenazn/goji 路径，则说明 vendor 已生效；若显示 $GOROOT/src/... 或 $GOPATH/pkg/mod/...，则 vendor 未被使用。
最后提醒：vendor/ 应纳入 Git 版本控制（git add vendor），确保团队与 CI 环境拥有完全一致的依赖快照；但需警惕类型兼容性风险——所有项目必须使用标准导入路径（如 "github.com/zenazn/goji"），切勿使用 vendor/xxx 等自定义路径导入，否则将触发 Go 类型系统报错：cannot use xxx.Handler as yyy.Handler（因包路径不同 → 类型不等价）。
Vendor 机制虽在 Go Modules 成为主流后逐渐演变为“兼容性方案”，但在离线构建、强审计需求或遗留系统迁移中仍具不可替代价值。掌握其精确触发条件与结构约束，是构建稳定、可复现 Go 工程的基石能力。
