依赖管理：从GOPATH到Go Modules的演进
聊到Go的依赖管理，我其实挺感慨的。2012年我刚接触Go时，那叫一个原始——所有代码都得扔到$GOPATH/src下面，版本？不存在的。你拉下来的依赖永远是master最新版，今天能编译，明天可能就挂了。
嗯，今天我们就来聊聊这段历史，以及现在怎么用好Go Modules。
GOPATH时代的痛
先说说GOPATH模式。说白了，你的项目代码必须放在$GOPATH/src目录下。比如你的项目叫myapp，那路径就是$GOPATH/src/myapp。
这有什么问题？我举个例子。你在两个项目里都用到了github.com/foo/bar这个库。项目A需要v1.0，项目B需要v2.0。但在GOPATH模式下，$GOPATH/src/github.com/foo/bar只能有一个版本。你怎么办？
我在2015年接手过一个遗留系统，就是因为这个原因，项目里直接copy了一份第三方库的源码到vendor目录。后来升级时，那叫一个痛苦——手动比对差异，生怕漏掉什么。
核心痛点：
- 没有版本概念，依赖永远是最新版
- 不同项目无法使用同一依赖的不同版本
- 构建不可复现——今天能编译，明天可能就不行了
- 私有仓库管理全靠git submodule或手动copy
vendor目录的出现
后来Go 1.5引入了vendor机制。你可以在项目根目录放一个vendor文件夹，把依赖的源码拷进去。编译时优先从vendor找依赖。
这算是一个进步，但治标不治本。vendor目录通常几百兆，提交到git里？太蠢了。不提交？那别人拉下来还得自己跑govendor sync。
我记得有一次，团队里新同事拉代码后忘了跑vendor sync，编译报了一堆错。排查了半天，发现是vendor目录没提交，而他的go版本和我们的不一样，解析出来的依赖版本也不同。嗯，这种坑我踩过不止一次。
Go Modules：终于来了
Go 1.11开始实验性支持Modules，1.13正式默认启用。说实话，这是我个人觉得Go生态里最值得称赞的改进之一。
怎么用？很简单：
# 初始化一个新模块
go mod init github.com/yourname/yourproject
# 添加依赖
go get github.com/foo/bar@v1.2.3
# 整理依赖
go mod tidy
# 下载所有依赖
go mod download执行完go mod init后，会生成两个文件：go.mod和go.sum。
go.mod长这样：
module github.com/yourname/yourproject
go 1.18
require (
github.com/foo/bar v1.2.3
github.com/baz/qux v0.5.0
)go.sum则记录了每个依赖的哈希值，用来校验完整性。这两个文件都要提交到git里。
我的建议：一定要把go.sum提交到版本控制。它保证了构建的可复现性。有人觉得它啰嗦想忽略掉，但相信我，别这么做。
版本选择机制
Go Modules使用语义化版本（SemVer）。格式是vMAJOR.MINOR.PATCH。
比如v1.2.3：
- MAJOR=1：不兼容的API变更
- MINOR=2：新增功能，向后兼容
- PATCH=3：bug修复
Go在解析依赖时，会遵循最小版本选择（MVS）算法。简单说就是：在满足所有依赖约束的前提下，选择尽可能低的版本。
举个例子：
- 项目A依赖
foo/barv1.2.0 - 项目B依赖
foo/barv1.3.0 - 项目C同时依赖A和B
那么Go会选择v1.3.0，因为它同时满足A（>=1.2.0）和B（>=1.3.0）的要求。
为什么不是选最新版？MVS算法的核心思想是「够用就好」。选最新版可能引入不稳定的变更，而选最低满足版本则更保守、更安全。我个人很喜欢这个设计——它避免了「依赖地狱」。
私有仓库管理
这是很多团队实际工作中最头疼的问题。公司内部的git仓库，怎么让Go Modules正确拉取？
假设你的私有仓库在git.company.com/team/project。直接go get会报错，因为Go默认走公共代理。
解决方案分三步：
- 配置GOPROXY：设置不走公共代理的私有仓库
- 配置GONOSUMCHECK：私有仓库不校验sum数据库
- 配置GONOSUMDB：同上，但更细粒度
具体配置：
# 设置私有仓库，多个用逗号分隔
go env -w GOPRIVATE=git.company.com
# 或者更细粒度
go env -w GOPRIVATE=git.company.com/team/*
# 也可以单独设置
go env -w GONOSUMCHECK=git.company.com
go env -w GONOSUMDB=git.company.com设置完GOPRIVATE后，Go会自动跳过公共代理和sum数据库，直接去你的git仓库拉取。
注意：私有仓库需要配置git认证。我建议用SSH方式，在~/.gitconfig里配置：
[url "ssh://git@git.company.com/"]
insteadOf = https://git.company.com/这样go get时就会自动走SSH，不用每次输密码。
replace指令：本地调试利器
开发时经常需要同时修改多个模块。比如你在项目A里发现了项目B的一个bug，想本地改完直接测试。
这时候replace指令就派上用场了：
module github.com/yourname/project-a
go 1.18
require (
github.com/yourname/project-b v1.0.0
)
// 本地替换
replace github.com/yourname/project-b => ../project-b这样项目A就会使用你本地的project-b代码，而不是从远程拉取。改完测试通过后，再提交project-b的修改，然后去掉replace。
我曾经用这个方式调试过一个跨三个模块的bug。当时线上有个数据不一致的问题，排查下来是A调用B，B又调用C，C里有个边界条件没处理好。如果没有replace，我得先提交C的修改，再更新B的依赖，再更新A的依赖...想想就头大。
小技巧：replace支持相对路径和绝对路径。我习惯用相对路径，这样同事拉下来也能直接用。另外，记得在提交前把replace去掉，或者用go mod tidy清理掉。
版本升级策略
依赖升级是个技术活。我见过有人直接go get -u ./...一把梭，结果编译不过，回退又麻烦。
我的做法是：
- 先看CHANGELOG：了解大版本间的breaking changes
- 逐个升级：不要一次升太多，每次升一个主要依赖
- 跑测试：升级完立刻跑单元测试和集成测试
- 用go vet检查：
go vet ./...可以发现一些潜在问题
举个例子，你要把gin从v1.6升级到v1.7：
# 查看当前版本
go list -m github.com/gin-gonic/gin
# 升级到指定版本
go get github.com/gin-gonic/gin@v1.7.0
# 或者升级到最新
go get github.com/gin-gonic/gin@latest
# 整理依赖
go mod tidy
# 跑测试
go test ./...如果升级后测试挂了，用go mod why看看是谁引入了这个依赖：
go mod why -m github.com/gin-gonic/gin这个命令会显示依赖链，帮你定位问题。
vendor目录的现代用法
虽然Go Modules不需要vendor也能工作，但在某些场景下vendor还是有用的：
- CI/CD环境：如果网络受限，可以提前下载好依赖
- 离线开发：没有外网时，vendor里的代码可以直接编译
- 审计需求：有些公司要求所有第三方代码必须经过安全审查，vendor方便做代码扫描
生成vendor目录：
go mod vendor编译时使用vendor：
go build -mod=vendor ./...我的建议：除非有特殊需求，否则不要提交vendor目录。它会让你的仓库变得臃肿，而且升级依赖时容易忘记同步vendor。用go.mod和go.sum就够了。
常见问题与避坑
最后分享几个我踩过的坑：
- go.sum不一致：多人协作时，不同人拉下来的go.sum可能不一样。解决方案是统一go版本，或者用
go mod tidy重新生成。 - 依赖循环：A依赖B，B又依赖A。Go Modules不允许循环依赖，编译会报错。这时候需要重构代码，把公共部分抽出来。
- 大版本升级：v1到v2是不兼容的。Go Modules要求v2及以上版本必须修改module path，比如
github.com/foo/bar/v2。这是强制规范，别想着绕过去。 - 代理超时：国内访问
proxy.golang.org可能很慢。我建议用七牛云或阿里云的Go代理：go env -w GOPROXY=https://goproxy.cn,direct。
嗯，依赖管理这块内容不少，但核心就一句话：用Go Modules，提交go.mod和go.sum，私有仓库配好GOPRIVATE。做到这三点，你的依赖管理基本就稳了。
下一章我们聊聊项目结构设计——怎么组织代码才能让后续的重构不那么痛苦。