go 语言通过单一、扁平的 `$gopath/src`（或 go modules）路径管理所有源码，编译时按导入路径唯一标识包，天然杜绝包内容重复加载——无论多少个依赖间接引用同一库，运行时仅存在一份已编译的包对象。
在 Java 生态中，Maven 或 Gradle 通过传递性依赖解析与版本仲裁机制处理 A → B → C 和 A → C 的共存问题；而 Go 的设计哲学截然不同：它不依赖“构建工具”来去重，而是从语言层和工具链层面保证包的唯一性与不可变性。
✅ Go 如何天然避免包重复？
Go 编译器以完整导入路径（如 projecta/libc）作为包的全局唯一标识符。只要所有代码都使用相同的导入路径引用同一个库，Go 就会：
- 在编译阶段只编译该包一次；
- 将其对象文件（.a）缓存于 $GOPATH/pkg/ 对应平台子目录下（如 linux_amd64/projecta/libc.a）；
- 所有依赖它的包（projecta/libb 和 projecta/a.go）均链接到同一份编译产物；
- 运行时内存中仅存在一份包变量与类型信息。
这意味着：你无需手动“消除重复”，Go 已在设计上消除了这一问题的前提——不存在真正的“两个 C 库副本”。你所担心的目录嵌套结构（如 LibB/src/LibC/）在标准 Go 工作区中是不合法且被明确禁止的。
? 错误结构示例与修正
你描述的原始结构：
AProject/
src/
LibC/ ← ❌ 非标准路径，无法被其他包正确导入
LibB/
src/
LibC ← ❌ 嵌套副本，Go 不识别为同一包
app.go这是对 Go 工作区模型的误解。Go 要求所有包源码必须位于 $GOPATH/src/
$GOPATH/src/projecta/
├── a.go # package main; import "projecta/libb", "projecta/libc"
├── libb/
│ └── b.go # package libb; import "projecta/libc"
└── libc/
└── c.go # package libc对应关键代码：
// $GOPATH/src/projecta/a.go
package main
import (
"projecta/libb"
"projecta/libc"
)
func main() {
libb.B() // 内部调用 libc.C()
libc.C() // 直接调用
}// $GOPATH/src/projecta/libb/b.go
package libb
import "projecta/libc" // 唯一、标准导入路径
func B() { libc.C() }? 提示：自 Go 1.11 起，推荐使用 Go Modules（go mod init projecta）替代 $GOPATH。此时包路径由 go.mod 中的 module 名定义（如 module projecta），依赖自动下载至 $GOPATH/pkg/mod，同样基于导入路径去重，且支持语义化版本控制，比传统 GOPATH 更健壮、可复现。
⚠️ 注意事项与最佳实践
- 永远不要手动复制依赖源码（如把 libc 放进 libb/src/）：这会导致 Go 视为两个不同包（projecta/libb/libc vs projecta/libc），引发编译错误或行为不一致。
- 统一使用绝对导入路径：避免相对导入（如 ./libc）或本地路径别名，确保可移植性。
- 启用 go mod tidy：在 Modules 模式下，它会自动分析所有 import 语句，精准拉取并记录直接/间接依赖，生成可验证的 go.sum。
- 理解 vendor 的定位：go vendor 是为离线构建打包依赖副本，但 vendored 包仍需通过标准导入路径引用——Go 依然只认路径，不认物理位置。
✅ 总结
Go 没有“依赖重复”的概念，因为它没有“依赖传递”意义上的“多版本共存”或“类加载隔离”。一个导入路径 = 一个包实例 = 一份编译结果。你的 Java 经验中需要 Maven 解决的问题，在 Go 里由语言规范和 go build 工具链静默完成。专注写好清晰的导入路径、合理划分模块边界，Go 自会为你保障简洁、高效、无歧义的依赖关系。
