Go 1.5+ 启用 vendor 机制后，vendor 目录仅在符合 Go 工作区规范的项目路径下生效；若将代码直接置于 $GOPATH/src/ 根目录而非子模块路径（如 src/myapp/），Go 工具链会忽略 vendor 并回退到全局 GOPATH 查找依赖。
go 1.5+ 启用 vendor 机制后，vendor 目录仅在符合 go 工作区规范的项目路径下生效；若将代码直接置于 `$gopath/src/` 根目录而非子模块路径（如 `src/myapp/`），go 工具链会忽略 vendor 并回退到全局 gopath 查找依赖。
在 Go 1.5 引入 vendor 目录机制后，Go 编译器会自动优先查找当前包所在目录的 vendor/ 子目录——但这一行为有严格前提：项目必须位于 $GOPATH/src/ 下的合法子路径中，且该路径需对应一个有效的导入路径（import path）。你遇到的问题根源正在于此。
你当前的项目结构是：
C:\Users\js\dev\my_project\rest\src\ ← 这里是 $GOPATH/src/ ├── main.go └── vendor/
而 go run main.go 执行时，Go 会尝试解析 main.go 所属的包路径。由于 main.go 直接位于 $GOPATH/src/ 下（即无子目录），Go 认为其导入路径为空或非法，因此跳过 vendor 查找逻辑，转而按传统方式在 $GOROOT/src 和所有 $GOPATH/src 路径中搜索依赖（如 gopkg.in/alecthomas/kingpin.v2），最终失败。
✅ 正确做法：将项目移至 $GOPATH/src/ 的命名子目录下，例如：
# 创建规范路径（以 your-project 为例） mkdir C:\Users\js\dev\my_project\rest\src\your-project # 移动代码和 vendor move C:\Users\js\dev\my_project\rest\src\main.go C:\Users\js\dev\my_project\rest\src\your-project\ move C:\Users\js\dev\my_project\rest\src\vendor C:\Users\js\dev\my_project\rest\src\your-project\ # 确保 GOPATH 设置正确（推荐仅设一个 GOPATH） set GOPATH=C:\Users\js\dev\my_project\rest # 进入项目目录并运行 cd C:\Users\js\dev\my_project\rest\src\your-project go run main.go # ✅ 此时 vendor 将被正确识别
此时 main.go 的隐含导入路径为 your-project，Go 工具链检测到同级存在 vendor/，便会优先从中解析依赖。
⚠️ 注意事项：
- 避免多 GOPATH 拼接：你原设置 GOPATH=C:\...\rest\;c:\...\go 容易引发路径冲突和 vendor 识别混乱，建议单一、明确的 GOPATH；
- Go 1.7+ 默认启用 vendor：无需额外标志，但路径合规性是前提；
- 现代替代方案：Go 1.11+ 推荐使用 Go Modules（go mod init），完全脱离 GOPATH 限制，vendor 行为由 go mod vendor 显式管理，更可靠且跨平台一致；
- 验证 vendor 是否生效：可运行 go list -f '{{.Dir}}' .，输出应包含 vendor 路径；或检查 go build -x 日志中是否出现 -vendor 相关参数。
总结：vendor 不是“任意目录下放个 vendor 就能用”，而是 Go 包路径模型的一部分。遵循 GOPATH/src/{import-path} 的经典结构，是保障 vendor 机制正常工作的基础。对于新项目，强烈建议直接启用 Go Modules，从根本上规避 GOPATH 和 vendor 路径陷阱。
