Go 1.6 引入了官方 vendor 机制，但要求 vendor 内部路径必须严格匹配导入路径（如 github.com/docker/libcompose 需置于 vendor/github.com/docker/libcompose），路径错位将导致 “cannot find package” 错误。
go 1.6 引入了官方 vendor 机制，但要求 vendor 内部路径必须严格匹配导入路径（如 `github.com/docker/libcompose` 需置于 `vendor/github.com/docker/libcompose`），路径错位将导致 “cannot find package” 错误。
在 Go 1.6 及后续版本中，vendor 机制默认启用（无需设置 GO15VENDOREXPERIMENT=1），但其路径解析规则极为严格：Go 工具链会将 import "github.com/docker/libcompose/cli/command" 映射为相对于 vendor/ 的完整路径 vendor/github.com/docker/libcompose/cli/command。这意味着你不能随意扁平化或修改 vendor 中的目录结构。
❌ 错误示例（导致报错）：
your-project/ ├── vendor/ │ └── docker/ # ❌ 错误：顶层目录应为 github.com，而非 docker │ └── libcompose/ # → 实际路径不匹配 import 路径 ├── main.go
✅ 正确结构（必须与 import 路径完全一致）：
your-project/ ├── vendor/ │ └── github.com/ # ✅ 必须存在且拼写准确（含 .com） │ └── docker/ │ └── libcompose/ # → 对应 import "github.com/docker/libcompose/..." ├── main.go
验证方式：运行 go list -f '{{.Dir}}' github.com/docker/libcompose/cli/command（在项目根目录下），若输出为空或报错，说明 vendor 路径未被识别；正确配置后应返回 vendor/github.com/docker/libcompose/cli/command。
⚠️ 注意事项：
- vendor 必须位于模块根目录（即 go build 执行目录）下，且不可嵌套在子目录中；
- 确保 GOPATH 和 GOROOT 未干扰 vendor 查找（Go 1.6+ 默认优先使用 vendor）；
- 推荐使用 go mod vendor（Go 1.14+）或工具如 govendor、dep（已归档）来生成合规 vendor 结构，避免手动复制出错；
- 若仍报错，可临时启用调试：go build -x 查看实际搜索路径，确认是否命中 vendor/...。
总结：vendor 不是“任意存放依赖的文件夹”，而是 Go 构建器按导入路径逐级映射的精确路径空间。修复的关键永远是——让 vendor/<import-path> 的目录层级与代码中 import 语句的字符串一字不差地对齐。
