Go 不支持将同一个包的代码分散在多个 GOPATH 路径下（如 src/ 和 vendor/src/），编译器只会加载第一个匹配路径中的包，导致测试无法识别 vendor 中的同名包。
go 不支持将同一个包的代码分散在多个 gopath 路径下（如 `src/` 和 `vendor/src/`），编译器只会加载第一个匹配路径中的包，导致测试无法识别 vendor 中的同名包。
在 Go 1.5 之前（即未启用 GO15VENDOREXPERIMENT=1）或非标准 vendor 模式下，你设置 GOPATH=/workspace;/workspace/vendor 的做法看似能“合并”两个源码树，但实际上 Go 工具链严格遵循 GOPATH 顺序查找规则：对每个导入路径（如 "package1"），它会依次遍历 GOPATH 中的每个工作区，在 src/ 子目录下搜索首个匹配的包。一旦在 /workspace/src/package1 中找到，就立即停止搜索，完全忽略 /workspace/vendor/src/package1 中的同名包。
这意味着：
- go build 或 go test 运行时，只会使用 /workspace/src/package1（优先级更高）；
- 即使你希望测试逻辑引用 /workspace/vendor/src/package1 的稳定版本，Go 也不会加载它；
- 尝试通过修改导入路径（如 import "vendor/src/package1"）是无效的——Go 不允许以 vendor/ 开头的合法导入路径，且该路径不符合包导入规范。
✅ 正确实践建议：
统一开发主路径：将正在开发的包（含测试）全部放在 GOPATH/src/package1 下；vendor 目录仅用于存放第三方依赖，而非你主动维护的包副本。
-
按项目隔离 vendor（推荐）：为每个 main package（如 cmd/myapp）建立独立目录结构，并在其下使用 vendor/（Go 1.6+ 原生支持）：
/myproject/ go.mod # 启用 module 模式（现代首选） cmd/myapp/main.go vendor/ # 由 go mod vendor 生成，仅影响本项目
-
升级至 Go Modules（强烈推荐）：彻底摆脱 GOPATH 限制。初始化模块后，package1 可作为本地 replace 或直接依赖：
cd /workspace/src/package1 go mod init example.com/package1
在其他项目中：
// go.mod require example.com/package1 v0.1.0 replace example.com/package1 => ../src/package1 // 开发时指向本地源
⚠️ 注意事项：
- 不要手动维护 GOPATH 多路径并期望包“合并”——Go 设计上禁止包重复定义；
- vendor/src/ 中放置自己正在开发的包，本质上违背了 vendor 的语义（vendor = 第三方只读快照）；
- 若必须共用逻辑，应将其拆分为独立可发布模块（如 github.com/you/corelib），再通过 go get 或 replace 管理。
总结：Go 的包模型是单实例、路径唯一、加载优先级明确的。解决此类问题的关键不是绕过规则，而是采用 Go Modules 等现代机制，让依赖关系显式、可复现、可隔离。
