该用 go mod tidy 而不是 go get 的场景是：刚克隆项目需拉齐依赖、删除 import 后清理残留 require 行、移除未使用的间接依赖；它只按 go.mod 约束对齐版本，不主动升级主版本或小版本。
直接运行 go mod tidy 就能更新并整理依赖，但要注意它只拉取满足当前 go.mod 约束的最新兼容版本；若要升级到特定大版本（比如 v2+），必须手动修改 require 行并执行 go get。
什么时候该用 go mod tidy 而不是 go get
go mod tidy 的核心作用是“对齐”：它会下载缺失的模块、移除未被引用的依赖，并按 go.mod 中声明的版本约束自动选取兼容版本。适合以下场景：
- 刚克隆一个项目，需要拉齐所有依赖
- 删了某段 import 但
go.mod还残留对应require行 - 想快速清理掉已不用的间接依赖（
// indirect）
它不会主动把 github.com/sirupsen/logrus 从 v1.8.1 升到 v1.9.0，除非你先改 go.mod 或用 go get 显式触发。
升级到新主版本（如 v2+）必须显式 go get
Go 模块对主版本号敏感。v2+ 必须带 /v2 后缀作为路径一部分，例如：
立即学习“go语言免费学习笔记（深入）”；
go get github.com/spf13/cobra@v1.7.0 go get github.com/spf13/cobra/v2@v2.0.0
如果直接 go mod tidy，它只会维持原有路径（如 github.com/spf13/cobra），不会自动切换到 github.com/spf13/cobra/v2 —— 因为这是两个独立模块。
常见错误现象：go build 报错 “cannot load github.com/xxx/v2: module github.com/xxx/v2@latest found” 但实际没出现在 go.mod 中，就是漏了 go get 这步。
go get -u 已过时，慎用
Go 1.16+ 默认关闭 -u（升级所有传递依赖）行为，且官方明确不鼓励无差别升级。原因包括：
- 可能引入不兼容变更（即使小版本，有些库违反 semver）
- 间接依赖升级后，本地代码未必经过充分测试
-
go get -u会忽略go.mod中的exclude和replace规则
替代做法是：精确指定模块和版本，例如 go get golang.org/x/net@master 或 go get golang.org/x/net@2023-05-10。
检查更新范围与验证兼容性
升级前建议先看哪些包会被动改动：
go list -u -m all # 列出可升级的模块（不含间接依赖）
go list -u -m -f '{{.Path}}: {{.Version}} -> {{.Latest}}' all # 显示当前 vs 最新版本
升级后务必跑测试：go test ./...，尤其关注 TestMain 或集成测试是否因依赖行为变化而失败。某些包（如 golang.org/x/text）在 minor 版本中也会调整 Unicode 处理逻辑，容易引发隐性 bug。
真正麻烦的不是命令怎么敲，而是搞清「哪个版本变更会影响我」——很多问题出在没看上游的 CHANGELOG，或者误以为 tidy 能替你做决策。
