go.mod 中 require 版本号表示最低允许版本，Go 采用最小版本选择（MVS）算法取满足所有依赖的最小兼容版本；升级应使用 go get 命令触发 MVS 重计算，而非手动修改 go.mod。
Go 1.11 引入 go.mod 后，版本管理不再依赖 GOPATH 和隐式 master 分支，而是由 go mod 命令显式控制——但这也意味着你必须主动理解 require 行的语义、go.sum 的校验逻辑，以及升级时的真实行为。
go.mod 中的版本号到底代表什么？
require github.com/sirupsen/logrus v1.9.3 这一行不是“锁定到 v1.9.3”，而是“最低允许使用 v1.9.3”（除非加 // indirect 或被其他依赖覆盖）。Go 默认采用 最小版本选择（MVS） 算法：整个模块图中，每个依赖只取满足所有要求的最小兼容版本。
- 如果另一个依赖要求
logrus v1.8.0，而你写的是v1.9.3，最终仍可能降级到v1.8.0（只要它满足你写的约束） -
v1.9.3是语义化版本，Go 会自动匹配v1.9.x范围内最高 patch 版本（如v1.9.4），但不会跨 minor 升级（如不升到v1.10.0） - 用
latest或master是危险的：它们不是稳定版本标识，且go get可能解析为 commit hash，导致不可重现构建
如何安全升级一个依赖到指定版本？
别直接改 go.mod 文件。用 go get 命令触发 MVS 重计算，并让 Go 自动更新 go.sum 和间接依赖。
- 升级到特定语义化版本：
go get github.com/sirupsen/logrus@v1.9.3
- 升级到最新 patch（保持 minor 不变）：
go get github.com/sirupsen/logrus@v1.9
- 升级到最新 minor（允许 v1.x 最高版）：
go get github.com/sirupsen/logrus@v1
- 强制忽略其他模块的约束、仅升级当前 require 行：
go get -u=patch github.com/sirupsen/logrus
（仅 patch 级）
执行后检查 go.mod 是否更新了版本号，go.sum 是否新增/变更了 checksum 行——若没变，说明该版本已在模块图中被满足，未实际升级。
立即学习“go语言免费学习笔记（深入）”；
为什么 go mod tidy 删除了我的 require 行？
go mod tidy 的作用是：清理未被任何 .go 文件 import 的依赖，并补全缺失的间接依赖。它不保留“你曾经手动加过但现已无用”的行。
- 如果你在代码里删掉了
import "github.com/pkg/errors"，再运行go mod tidy，对应require行就会消失 - 若某依赖仅被测试文件（
*_test.go）引用，go mod tidy默认不保留它；需加-t参数：go mod tidy -t
- 想临时保留一个未使用的依赖（比如为后续开发预留），可在任意
.go文件中加一行注释式导入：_ "github.com/xxx/yyy"
（注意下划线），再运行tidy
升级后编译失败，常见原因和排查点
Go 不做运行时兼容性保证，minor 升级（如 v1.9 → v1.10）可能引入破坏性变更。错误往往不来自你的代码，而是依赖链中的中间层。
- 先看报错是否指向某个函数不存在或签名变化：查该依赖的
CHANGELOG.md或 GitHub Releases，确认是否为 breaking change - 运行
go list -m -u all
查看哪些模块有可用升级，再用go list -m -versions github.com/xxx/yyy
看可选版本范围 - 若怀疑是间接依赖冲突，用
go mod graph | grep xxx
查谁引入了旧版 - 临时锁定某依赖版本（绕过 MVS）：
go get github.com/xxx/yyy@v1.2.3
后，再go mod edit -replace github.com/xxx/yyy=github.com/xxx/yyy@v1.2.3
真正麻烦的从来不是“怎么升级”，而是升级后发现某个 transitive dependency 的旧版被意外拉入，且它的 bug 在新 Go 版本下才暴露——这时得靠 go mod graph 和逐层 go list -m -f '{{.Indirect}}' xxx 定位源头。
