Go工具链不支持将同一包的代码分散在多个GOPATH路径下（如/workspace/src/package1和/workspace/vendor/src/package1），它始终只加载GOPATH中首个匹配路径下的包，导致测试无法识别vendor中同名包的定义。
go工具链不支持将同一包的代码分散在多个gopath路径下（如`/workspace/src/package1`和`/workspace/vendor/src/package1`），它始终只加载gopath中首个匹配路径下的包，导致测试无法识别vendor中同名包的定义。
在Go 1.5之前（即未启用GO15VENDOREXPERIMENT=1）的手动vendor方案中，将/workspace/vendor加入GOPATH（如GOPATH=/workspace:/workspace/vendor）看似能“覆盖”依赖，实则引入了严重的包路径冲突风险。
❌ 为什么这种结构不可行？
Go编译器按GOPATH顺序扫描src/子目录，一旦在/workspace/src/package1中找到该包，就立即停止搜索，完全忽略/workspace/vendor/src/package1中的同名包。这意味着：
- import "package1" 总是解析到 /workspace/src/package1；
- 即使你修改了 vendor 中的 package1，测试也永远无法调用其代码；
- 同一包名在不同路径下被视为两个独立包（若强行导入会报错：imported and not used 或 redeclared in this block）。
✅ 正确实践：统一开发主包，按需 vendoring
推荐采用清晰、可维护的项目结构：
/workspace
/src
/myproject # 主应用或库（含所有开发中的代码）
main.go
package1/ # 当前正在开发的 package1 —— 全部放在这里
foo.go
foo_test.go
/somepackage # 独立第三方依赖（由 vendor 管理）
/anotherpackage若需复用 package1 并同时维护其外部依赖，应：
立即学习“go语言免费学习笔记（深入）”；
- 将 package1 作为独立模块（如 GitHub 仓库）开发；
- 在 myproject 中通过 go get 引入，并使用 Go Modules（Go 1.11+）进行 vendor 管理：
cd /workspace/src/myproject go mod init myproject go get package1@latest go mod vendor # 生成 ./vendor/ 目录
- 所有测试、开发、构建均基于 myproject 下的单一 package1 路径，避免 GOPATH 多路径歧义。
⚠️ 注意事项
- 不要滥用多 GOPATH：GOPATH=/a:/b 是历史遗留机制，易引发不可预测的包解析行为，官方早已弃用；
- Go Modules 是标准解法：自 Go 1.11 起，Modules 已取代 GOPATH-based vendor 方案，提供确定性依赖、版本控制与隔离；
- 若必须兼容旧环境，请确保 package1 仅存在于一个路径下（推荐放在 src/），vendor 中仅保留纯第三方依赖，而非自身包的副本。
总之，Go 的设计哲学是“一个包，一个源”，跨路径拆分违背其构建模型。重构为模块化、单源开发，才是长期可维护的正道。
