Go 工具链不支持将同一包的代码分散在多个 GOPATH 路径下（如 src/ 和 vendor/src/），编译时仅加载首个匹配路径中的包，导致测试无法识别 vendor 中的同名包。
go 工具链不支持将同一包的代码分散在多个 gopath 路径下（如 `src/` 和 `vendor/src/`），编译时仅加载首个匹配路径中的包，导致测试无法识别 vendor 中的同名包。
在 Go 1.5 之前（即未启用 GO15VENDOREXPERIMENT=1 或现代模块时代），开发者有时会通过多目录 GOPATH（如 GOPATH=/workspace:/workspace/vendor）尝试“混合”源码与 vendor 依赖。但这种做法存在根本性限制：Go 的构建系统按 GOPATH 列表顺序搜索包，一旦在 /workspace/src/package1 中找到 package1，就不会再检查 /workspace/vendor/src/package1 —— 即使你希望测试引用 vendor 版本，实际编译仍绑定到 src/ 下的版本。
这并非配置问题，而是 Go 设计原则：一个导入路径（如 "package1"）必须唯一对应一个物理包路径，且由 GOPATH 前置优先级决定。 因此，以下结构注定失败：
/workspace
/src
/package1 # ← 编译器永远优先使用此处（即使你写 test 期望 vendor 版本）
/vendor
/src
/package1 # ← 永远被忽略！同名导入路径冲突
✅ 正确实践方案：
- 统一开发主路径：所有可编辑源码（含待测包）应仅存在于 GOPATH/src/ 下（如 /workspace/src/package1），vendor 目录仅用于存放第三方只读依赖，而非自身包的副本；
- 若需测试 vendor 中的包：应将该包视为外部依赖，通过完整导入路径（如 "github.com/yourorg/package1"）引入，并确保其不在 GOPATH/src/ 中重复存在；
- 升级至 Go Modules（推荐）：彻底弃用 GOPATH 多路径 hack。在 package1 根目录运行 go mod init github.com/yourorg/package1，然后用 go test 直接运行——模块系统会精确解析 require 声明的版本，不再受文件系统路径歧义干扰。
⚠️ 注意事项：
- 不要手动维护 vendor/src/package1 与 src/package1 并存，这违反 Go 包唯一性约定；
- go build 和 go test 均不会合并或覆盖同名包，只会静默忽略后续路径；
- 若必须隔离环境（如验证 patch 效果），应使用独立 GOPATH + go install 构建二进制，而非源码级混用。
总结：Go 的包模型基于“单路径单包”强约束。解决此类问题的关键不是绕过规则，而是回归标准工作流——以模块化（Go Modules）替代 GOPATH 多路径，以清晰职责划分（src = 开发代码，vendor = 锁定依赖）替代模糊共存。
