升级单个依赖用 go get @latest，确保项目依赖干净准确必须执行 go mod tidy；前者精准更新版本，后者扫描代码并同步 go.mod/go.sum，二者分工协作不可替代。

升级依赖该用 go get -u 还是 go mod tidy？

直接说结论：升级单个依赖用 go get -u（或更推荐 go get @latest），而确保整个项目依赖干净、准确，必须跟上 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 失败、本地能跑线上报错的问题，根源都在这一步被跳过了。