本文详解 Go 1.8 下 Glide 无法识别 vendor 目录的根本原因——Go 官方在 1.5 引入 vendor 机制，但仅当项目位于 GOPATH/src 的合法子路径（如 github.com/user/repo）下时，go build 才会自动启用 vendor 查找逻辑；否则仍回退至 GOPATH/src 和 GOROOT，导致“cannot find package”错误。
本文详解 go 1.8 下 glide 无法识别 vendor 目录的根本原因——go 官方在 1.5 引入 vendor 机制，但仅当项目位于 gopath/src 的合法子路径（如 github.com/user/repo）下时，go build 才会自动启用 vendor 查找逻辑；否则仍回退至 gopath/src 和 goroot，导致“cannot find package”错误。
在 Go 1.8 中，vendor 机制虽已原生支持，但其生效有严格前提：项目源码必须置于 $GOPATH/src/ 下符合 Go 包导入路径规范的子目录中（例如 github.com/username/myproject），而非直接放在 $GOPATH/src/ 根目录。你当前的项目结构：
/Users/myName/go/src/
main.go ← ❌ 错误：顶层文件不构成合法包路径
vendor/ ← ❌ vendor 目录孤立存在，无父包上下文
会导致 go build 完全忽略 vendor/，转而按传统方式搜索 $GOROOT/src 和 $GOPATH/src —— 显然 github.com/julienschmidt/httprouter 并未安装在这些位置，因此报错。
✅ 正确做法是重构项目路径，使其匹配 Go 的模块导入约定：
# 1. 创建符合规范的包路径（以 GitHub 风格为例） mkdir -p $GOPATH/src/github.com/yourname/myapp # 2. 将代码移入该路径 mv /Users/myName/go/src/main.go $GOPATH/src/github.com/yourname/myapp/ mv /Users/myName/go/src/vendor $GOPATH/src/github.com/yourname/myapp/ # 3. 进入项目目录并验证 cd $GOPATH/src/github.com/yourname/myapp glide install # 确保 vendor 更新一致 go build # ✅ 此时 vendor 自动生效
此时 go build 会按如下顺序解析依赖：
- 当前目录下的
vendor/（命中github.com/julienschmidt/httprouter） - 回退至
$GOPATH/src/（仅当 vendor 缺失时） - 最终回退至
$GOROOT/src/
⚠️ 注意事项：
- Glide 已于 2019 年正式归档（archived），强烈建议升级至 Go Modules（
go mod）：自 Go 1.11 起原生支持，无需 GOPATH，vendor可通过go mod vendor按需生成，且版本锁定精准、可复现。 - 若必须使用 Glide，请确保
glide.yaml中package:字段与实际导入路径一致（如package: github.com/yourname/myapp），否则glide install可能生成无效 vendor。 -
go env GOPATH输出路径必须与实际项目路径一致；若使用多 GOPATH，需确认glide install和go build均作用于同一环境。
总结：Go 的 vendor 不是“任意目录下放个 vendor 就能用”，而是深度绑定于 GOPATH + 标准包路径 的双约束模型。理解这一设计逻辑，才能避免在 Go 1.5–1.10 时代反复踩坑。迁移至 Go Modules 是面向未来的最优解。
