go.mod 依赖管理与语义化版本是怎么工作的？
一句话结论：go.mod 声明模块路径、Go 版本与直接依赖，go.sum 用哈希锁定每个依赖的内容；版本解析采用 MVS（最小版本选择）——在所有依赖路径要求的版本里取最大者，保证构建可复现；对外发布遵循语义化版本，主版本不低于 2 时模块路径要带 /vN 后缀。
go.mod 里的关键指令
| 指令 | 作用 |
|---|---|
| module | 模块路径（一般等于仓库地址，v2+ 带 /vN） |
| go | 语言/工具链版本（1.21+ 逐模块控制语言特性） |
| require | 直接依赖与版本；// indirect 标记间接依赖 |
| replace | 本地替换（开发调试、fork、内网镜像） |
| exclude | 剔除有问题的特定版本 |
| toolchain | 指定所需的工具链版本（1.21+） |
日常操作：go get 新增或升级依赖、go mod tidy 整理（补 indirect、删未用）、go mod vendor 生成 vendor 目录、go mod download 预热缓存。
语义化版本与 MVS
- 版本形如 vMAJOR.MINOR.PATCH，如 v1.2.3；预发布 v1.2.3-rc.1 排序更低。
- v0.x 不承诺兼容；v1+ 的破坏性变更必须升 MAJOR。
- 模块路径 v2/v3… 必须写成 module example.com/m/v2，import 路径同步带 /v2——这是 Go 模块区别于“换个 tag 硬升级”的关键。
- MVS：A 依赖 B v1.2，C 依赖 B v1.5，最终选 v1.5，保证新增依赖不会把别人的版本悄悄降级。
module github.com/me/project
go 1.22
require (
github.com/gin-gonic/gin v1.10.0
golang.org/x/sync v0.7.0 // indirect
)
replace github.com/me/project => ../project
go.sum 同时记录 go.mod 与源码压缩包的哈希，内容被篡改或投毒时校验失败；提交仓库时 go.mod 与 go.sum 都要入库。
常见追问 / 记忆点
- 追问：公司内网常用 replace 或 GOPROXY 做什么？——replace 处理本地与未发布模块，GOPROXY 走私有代理加速并防篡改。
- 追问：require 里出现 v1.0.0+incompatible 是什么？——模块没有 go.mod 且主版本较高的兼容标记，尽量升级到带 go.mod 的版本。
- 记忆点：MVS 取最大需求版本；v2+ 路径带 /vN；go.sum 锁内容；tidy 后提交两个文件。