📚 课程目录第2章 Go语言依赖管理演进

2. Go 语言依赖管理演进：GOPATH、Go Modules、依赖版本控制基础

Go 语言的依赖管理经历了从简陋到成熟的演进过程。理解这段历史，有助于你理解当前 Go Modules 的设计哲学，以及为什么在领域驱动设计的实践中，依赖管理是解耦的基础设施。

2.1 第一阶段：GOPATH 模式（Go 1.11 之前）

在 Go 1.11 之前，所有 Go 代码必须存放在 $GOPATH/src 目录下。这种模式没有内置的版本控制能力，依赖管理完全依赖社区工具。

  核心痛点： 无法区分同一依赖的不同版本，所有项目共享同一个依赖副本，导致“依赖地狱”。

特性	GOPATH 模式	问题
项目位置	必须位于 `$GOPATH/src` 下	无法自由选择项目目录
版本控制	无内置版本概念	依赖锁定困难，构建不可复现
依赖共享	全局共享 vendor 或 GOPATH	不同项目依赖冲突
社区工具	依赖 glide、dep、govendor 等	工具碎片化，标准不统一

# GOPATH 模式下的典型目录结构
$GOPATH/
├── bin/
├── pkg/
└── src/
    ├── github.com/
    │   └── user/
    │       └── myproject/
    │           ├── main.go
    │           └── go.mod (早期无此文件)
    └── golang.org/
        └── x/
            └── text/

2.2 第二阶段：Go Modules 的诞生（Go 1.11+）

Go 1.11 引入了实验性的 Go Modules 支持，Go 1.13 将其设为默认模式。Go Modules 彻底解决了版本控制问题，并引入了语义化版本（SemVer）作为依赖版本标准。

关键转变： 从“代码位置决定身份”变为“模块路径 + 版本号决定身份”。项目不再受限于 $GOPATH，可以在任意目录下工作。

# 初始化一个新模块
go mod init github.com/mycompany/myproject

# 添加依赖（自动更新 go.mod 和 go.sum）
go get github.com/gin-gonic/gin@v1.9.1

# 整理依赖
go mod tidy

# 查看依赖图
go mod graph

2.3 核心文件：go.mod 与 go.sum

Go Modules 通过两个核心文件管理依赖：

go.mod：声明模块路径、Go 版本、直接依赖及其版本。
go.sum：记录所有依赖的哈希值，用于构建验证和防篡改。

// go.mod 示例
module github.com/mycompany/myproject

go 1.21

require (
    github.com/gin-gonic/gin v1.9.1
    github.com/stretchr/testify v1.8.4 // indirect
    go.uber.org/zap v1.26.0
)

// go.sum 示例（部分）
github.com/gin-gonic/gin v1.9.1 h1:abc...xyz
github.com/gin-gonic/gin v1.9.1/go.mod h1:def...ghi
github.com/stretchr/testify v1.8.4 h1:ghi...jkl

2.4 依赖版本控制基础：语义化版本（SemVer）

Go Modules 强制使用语义化版本格式：vMAJOR.MINOR.PATCH。

版本段	含义	示例	兼容性
MAJOR	主版本号，不兼容的 API 变更	v2.0.0	不向后兼容
MINOR	次版本号，向下兼容的功能新增	v1.3.0	向后兼容
PATCH	修订号，向下兼容的问题修正	v1.3.1	向后兼容

重要规则： 当主版本号大于等于 2 时，模块路径必须包含 /v2 后缀。例如：github.com/user/repo/v2。这是 Go Modules 实现多版本并存的机制。

2.5 依赖版本选择机制：最小版本选择（MVS）

Go Modules 采用最小版本选择（Minimal Version Selection, MVS）算法，而不是像 npm 或 Maven 那样使用“最近优先”或“依赖仲裁”。MVS 的核心原则是：使用所有依赖声明的最大兼容版本。

// 依赖关系示例
// A 依赖 B v1.2.0
// C 依赖 B v1.3.0
// 最终选择 B v1.3.0（取最大兼容版本）

// 如果 A 依赖 B v1.2.0
// C 依赖 B v2.0.0（主版本不同）
// 则 A 和 C 各自使用自己的 B 版本，互不干扰

  MVS 的优势： 构建确定性高，不会出现“依赖地狱”中的版本冲突；同时支持同一模块的不同主版本共存，这在领域边界解耦中非常有用——不同限界上下文可以依赖同一库的不同主版本。

2.6 依赖管理在领域边界中的意义

在 DDD 实践中，每个限界上下文（Bounded Context）通常对应一个独立的 Go Module。Go Modules 的版本隔离能力，使得不同上下文可以：

独立演进：每个上下文可以自由升级自己的依赖，不影响其他上下文。
版本共存：当两个上下文需要同一库的不同主版本时，Go Modules 天然支持。
构建确定性：go.sum 确保每次构建使用相同的依赖版本，避免“在我机器上能跑”的问题。
最小依赖原则：每个上下文只引入自己需要的依赖，避免全局依赖污染。

实践建议： 在领域驱动设计的项目中，建议每个限界上下文独立为一个 Go Module，并维护自己的 go.mod。上下文之间的依赖通过接口（interface）和依赖注入（DI）来解耦，而不是直接依赖具体实现。