升级单个依赖用 go get @latest，确保项目依赖干净准确必须执行 go mod tidy；前者精准更新版本，后者扫描代码并同步 go.mod/go.sum，二者分工协作不可替代。
升级依赖该用 go get -u 还是 go mod tidy？
直接说结论：升级单个依赖用 go get -u（或更推荐 go get ），而确保整个项目依赖干净、准确，必须跟上 go mod tidy。两者不是替代关系，而是分工明确的协作流程——前者改版本，后者做校准。
go get -u 实际做了什么？为什么容易出错
go get -u 会递归更新指定包及其所有直接/间接依赖到「最新兼容版本」（即满足语义化版本约束的最高 minor/patch 版本），并写入 go.mod。但它不检查你的代码是否真的用了这些包，也不清理残留项。
- 常见错误现象：
go get -u github.com/spf13/cobra后，go.mod里多出一堆// indirect条目，但项目根本没用到其中某些包（比如golang.org/x/sys） - 风险点：它可能把间接依赖升到不兼容的新主版本（如 v2→v3），而你的代码没适配，编译或运行时报错
- 更安全的替代写法：
go get github.com/spf13/cobra@latest
或指定版本：go get github.com/spf13/cobra@v1.9.0
—— 明确控制目标版本，避免隐式升级“意外连带包”
go mod tidy 的真实作用：不是升级，是“对齐”
go mod tidy 不主动升级任何依赖，它的核心逻辑是：扫描全部 .go 文件中的 import 语句，然后让 go.mod 和 go.sum 严格匹配当前代码实际需要的依赖。它既补缺，也删冗余。
- 典型使用场景：
- 刚删掉一个
import "github.com/go-redis/redis/v9"，但go.mod还留着那行 —— 运行go mod tidy后自动移除 - 新增了
import "gopkg.in/yaml.v3"却忘了拉包 ——go mod tidy自动下载并写入go.mod
- 刚删掉一个
- 注意：它不会帮你把
v1.8.0升到v1.9.0，哪怕新版本已存在缓存中；也不会修复因go get -u导致的间接依赖膨胀 - 务必在每次
go get后运行：go get github.com/gin-gonic/gin@v1.9.1
go mod tidy
升级依赖的标准操作流（别跳步）
真正安全的升级不是靠一个命令搞定，而是三步闭环：
-
第一步：明确升级目标 —— 查文档确认新版本是否兼容，尤其注意 major 版本变更（如
v1→v2需路径加/v2） -
第二步：精准获取版本 —— 用
go get或@vX.Y.Z @latest，避免-u的不可控连带升级 -
第三步：强制对齐现场 —— 立即执行
go mod tidy，清理// indirect垃圾、补全缺失校验、验证 import 是否真能解析
漏掉第三步，go.mod 就只是“你曾经想升级过”的快照，不是项目当前的真实依赖状态。很多 CI 失败、本地能跑线上报错的问题，根源都在这一步被跳过了。
