前言
如果你经历过这些场景，你就会理解 Go 依赖管理为什么一定会演进：
- 昨天还能编译，今天就不行了：同一份代码，拉下来却跑不起来
- CI 和本地不一致：流水线拉到的依赖和你本机不是同一份
- 同一个依赖，不同项目互相"污染"：你升级 A 项目，B 项目突然坏了
- 版本不可控：你想要"固定在某个版本"，却只能祈祷外部世界别变
这篇不讲"怎么用"，只把历史脉络捋顺：Go 是怎么从 GOPATH 走到 Go Module 的，以及每一步试图解决什么问题。
1. GOPATH 时代：依赖管理是"约定"而不是"机制"
在 Go 1.11 之前，Go 的工程组织强依赖 GOPATH 工作区。直观理解：
- 代码放哪 ：
$GOPATH/src/<import path>/... - 怎么引用 ：
import的路径往往与代码所在的仓库路径（或约定的路径）强绑定，Go 会直接去 $GOPATH/src/github.com/gin-gonic/gin 看看在不在 - 怎么获取 ：
go get负责把远端代码拉到 GOPATH 里
这套模式简单直接，但它的关键特征是："全局工作区 + 默认取最新"。
text
$GOPATH/
├── src/
│ └── github.com/gin-gonic/gin
├── pkg/
└── bin/1.1 GOPATH 的优势：简单、直观、上手快
- 零配置：不需要额外文件描述依赖
- 行为统一：大家都在一个工作区里，工具链也更容易假设目录结构
- 学习成本低：看到 import path，基本能猜到代码在哪儿
1.2 GOPATH 的硬伤：缺少"可复现构建"的基础
当项目变大、依赖变多，GOPATH 的问题会集中爆发：
- 没有版本语义：依赖通常以分支/提交的"当前状态"存在，很难表达"我需要 v1.2.3"
- 不可复现：今天拉到的依赖内容，明天可能就变了
- 全局污染：同一份依赖在 GOPATH 里是共享的，不同项目需求冲突时只能互相妥协
- 迁移/协作成本高：换台机器、换个环境，能不能跑起来很靠运气（和缓存）
一句话：GOPATH 解决了"代码怎么放"，但没解决"依赖怎么定"。
2. 第一次重要转折：vendor（把依赖"拷进项目里"）
为了让构建更稳定，Go 社区很自然地走向一个方向：把依赖固定到项目里。
这就是 vendor/ 目录出现的背景。
2.1 vendor 的直觉：项目自包含
- 依赖跟着项目走 ：把第三方包的源码放进项目的
vendor/ - 构建更可控 ：只要
vendor/没变，依赖就不会"飘"
它解决了 GOPATH 时代最痛的两件事：
- 同一个项目在不同机器上更一致
- 不会被 GOPATH 里别的项目升级依赖所影响
2.2 vendor 的代价：稳定换来的"笨重"和"碎片化"
vendor 并不是终局方案，因为它把"版本管理"换成了"源码拷贝管理"：
- 体积与重复：每个项目都携带一份依赖源码，仓库变大、重复严重
- 更新困难：升级某个依赖不是"改版本号"，而是"替换一坨代码"
- 工具链不统一：到底用什么工具把依赖放进 vendor？不同团队选择不同方案
- 依然绕不开 GOPATH：在很长一段时期里，vendor 只是补丁，没彻底改变工程模型
vendor 证明了一点："可复现"是刚需；但它也暴露出：仅靠目录约定，难以支撑复杂依赖治理。
3. 社区工具阶段：用"锁定文件 + vendor"补齐版本能力
在官方机制缺位时，社区工具就会自然生长。它们大多围绕同一个目标：
把依赖"锁住"，让构建可复现。
这类工具通常会做两件事：
- 记录依赖的精确来源（版本/提交等）
- 把依赖落到项目内（常见就是 vendor）
这一阶段的意义在于：它让 Go 社区形成了共识------
- 必须有"机器可读"的依赖描述
- 必须能复现出同一份依赖图
- 必须能在不同环境稳定构建
但工具百花齐放也带来问题：
- 标准不统一：格式、语义、边界都不一致
- 与工具链割裂 ：构建、下载、版本选择不在
go工具本体里 - 迁移成本高：不同工具之间互转困难，团队协作有额外摩擦
当"需求清晰但实现割裂"时，官方机制的出现几乎是必然。
4. Go Module：把依赖管理变成"语言工具链的一等公民"
Go Module 的核心变化不是多了两个文件，而是工程模型发生了改变：
依赖管理从"全局工作区的约定"，变成了"项目级的、可计算的机制"。
4.1 依赖从"隐式"变成"显式"
go.mod：声明"我是谁（module path）"以及"我依赖谁（require）"go.sum：记录"我拿到的依赖内容应该长什么样"（用于一致性校验）
这让依赖变成了可以被工具链直接理解和计算的输入，而不是散落在 GOPATH 或某个工具的私有文件里。
4.2 依赖从"拷贝进项目"变成"有缓存的获取"
Go Module 默认不要求把依赖拷进仓库。
它把依赖获取与复用做成了工具链能力：
- 项目只描述依赖
- 工具链负责获取与缓存
- 同一份依赖版本可在本机复用，避免每个项目重复携带
4.3 版本从"随缘"变成"可推导、可收敛"
真实项目里依赖是一个图：A 依赖 B，B 依赖 C......
Go Module 需要回答的是：整张依赖图最终选哪个版本？
它选择了一条非常工程化的路线：让版本选择有稳定规则、结果可预期，并且能在大规模依赖图下高效运行。
（版本选择的具体算法会在后续专门展开，这里只强调：它不再是"谁先被拉下来就用谁"。）
4.4 一致性与供应链：校验成为默认行为
当依赖变成"网络获取 + 本地缓存"，一致性校验就变得关键。
Go Module 把"同一版本依赖在不同机器应当一致"这件事内建进流程里：它不依赖团队自觉，而是工具链默认就会做。
5. 关键时间线：从补丁到默认
为了把脉络串起来，你可以把演进理解成三段：
- GOPATH 时代：依赖管理主要靠约定，缺少版本与复现能力
- vendor/社区工具时代：用工程实践补齐缺失能力，但标准割裂
- Go Module 时代：官方机制统一语义、统一入口、统一行为
Module 从"可选"走到"默认"，本质是生态与工具链都在向 可复现、可协作、可扩展 收敛。
6. 演进背后的主线：Go 一直在解决同一个问题
无论是 GOPATH、vendor、还是 Go Module，它们都围绕同一条主线在权衡：
- 简单：上手容易、心智模型清晰
- 可复现：同样的输入得到同样的依赖与构建结果
- 可协作：多人、多机、多环境下行为一致
- 可扩展：依赖图变大后依然可管理、可计算、可缓存
GOPATH 把"简单"做到极致，但可复现与协作能力不足；
vendor 用"把代码拷进来"换来稳定，但代价是笨重与割裂；
Go Module 则把这些工程诉求收敛到统一机制里。
下一篇开始，我们就可以在这条主线上，把 Go Module 的关键概念逐个钉牢：module、version、sum 到底是什么，它们分别解决哪类问题。