本文详解 glide 在 go 1.7+ 环境下构建失败的核心原因——vendor 目录未生效，并给出跨平台可复用的解决方案，重点说明 gopath 结构约束、项目路径规范及 go build 行为机制。
本文详解 glide 在 go 1.7+ 环境下构建失败的核心原因——vendor 目录未生效，并给出跨平台可复用的解决方案，重点说明 gopath 结构约束、项目路径规范及 go build 行为机制。
Glide 是 Go 生态中早期广泛采用的 vendor 包管理工具（2016–2018 年主流），其核心价值在于通过 glide.yaml 和 glide.lock 实现可重现的依赖锁定，并将第三方包完整复制至项目根目录下的 vendor/ 子目录中。然而，一个极易被忽视的关键前提是：Go 工具链仅在特定路径结构下才自动启用 vendor 机制。
根据 Go 官方规范（Go 1.5+ 引入 vendor 支持），go build 会自动识别并优先使用当前包所在目录树中的 vendor/ 子目录，但该行为仅当项目源码位于 $GOPATH/src/ 下的合法导入路径中时才可靠触发。例如：
# ✅ 正确：项目路径符合 Go 导入约定（如 github.com/yourname/project） $GOPATH/src/github.com/yourname/project/ ├── glide.yaml ├── glide.lock ├── main.go └── vendor/ # ❌ 错误：项目位于任意临时路径（如 /tmp/project 或 ~/myproj） /tmp/project/ ├── glide.yaml ├── vendor/ # 即使存在且内容完整，go build 也会忽略！ └── main.go
你遇到的错误日志明确揭示了问题本质：
cannot find package "github.com/jaxxstorm/flexvolume" in any of:
/usr/lib/golang/src/... (GOROOT)
/tmp/go/src/... (GOPATH)
这说明 go build 根本没有扫描 ./vendor/，而是直接去 $GOROOT 和 $GOPATH/src 中查找依赖——因为当前工作目录 不在 $GOPATH/src 的子路径内。
✅ 解决方案（推荐且稳定）：
将项目软链接（symlink）或直接克隆到 $GOPATH/src 下的标准路径中：
# 假设 GOPATH=/home/user/go，项目原在 ~/work/ploop mkdir -p $GOPATH/src/github.com/jaxxstorm ln -sf ~/work/ploop $GOPATH/src/github.com/jaxxstorm/ploop # 进入标准路径后执行 cd $GOPATH/src/github.com/jaxxstorm/ploop glide install # 确保 vendor 已就绪 go build -o ploop main.go # ✅ 成功！vendor 自动生效
⚠️ 注意事项：
-
不要依赖
GOVENDOREXPERIMENT：该环境变量在 Go 1.6+ 已默认启用，Go 1.7.4 完全支持 vendor，无需手动设置； -
避免
go build ./...在非 GOPATH 路径运行：即使有vendor/，Go 仍按传统方式解析 import 路径； -
验证路径合法性：运行
go list -f '{{.ImportPath}}' .，输出应为类似github.com/jaxxstorm/ploop的有效导入路径； -
现代替代建议：Glide 已于 2018 年归档（archived），官方推荐迁移到 Go Modules（
go mod init）。若需长期维护，建议逐步迁移，但对遗留项目，严格遵守 GOPATH 结构仍是最快落地的解法。
总结：Glide 的 vendor 机制不是“独立运行”的黑盒，而是深度集成于 Go 工具链的路径感知系统。项目必须“住在 $GOPATH/src 里”，vendor 才能被看见——这不是 Glide 的缺陷，而是 Go 早期依赖管理的设计契约。
