go get -u 默认只更新直接导入的包，不递归升级间接依赖；升级至最新兼容主版本（如v1.x），不跨主版本；推荐使用 go get -u=patch 或 go get -u=minor 精准控制升级粒度。
go get -u 会更新哪些依赖
go get -u 默认只更新直接导入的包（即 import 语句里显式声明的），不会递归升级间接依赖（transitive dependencies）。它会拉取该包的最新 主版本兼容分支（如 v1.x 的最新 patch/minor），但不会跨主版本（比如不从 v1.5.0 升到 v2.0.0，除非你显式写 go get example.com/pkg@v2.0.0）。
容易踩的坑：
- 误以为
go get -u能“一键全量升级”，实际它对go.mod中已存在的间接依赖基本不碰 - 如果某个间接依赖被多个直接依赖引用，且版本不一致，
go get -u不会自动统一它们——得靠go mod tidy或手动指定 - Go 1.16+ 默认启用
GOPROXY，若代理不可用或返回过期缓存，-u可能拉到旧版，建议加-v观察真实 fetch 行为
升级单个包并固定版本
最可控的方式是明确指定版本号，尤其用于修复 CVE 或锁定行为。例如升级 golang.org/x/net 到 v0.25.0：
go get golang.org/x/net@v0.25.0
这会做三件事：下载该版本、更新 go.mod 中对应条目、自动运行 go mod tidy 清理未使用依赖。
立即学习“go语言免费学习笔记（深入）”；
注意点：
- 版本号必须存在且可解析（支持
vX.Y.Z、commit hash、branch name，但后者不推荐用于生产） - 如果该包在
go.mod中是 indirect，升级后可能变成 direct（因其他包依赖它，而你又显式调用了它的 API） - 执行后检查
go.mod：确认// indirect标记是否合理，避免意外引入强依赖
批量升级所有可兼容依赖（go 1.18+ 推荐）
Go 1.18 引入了 go get -u=patch 和 go get -u=minor，比裸 -u 更精准：
-
go get -u=patch：只升 patch 版本（如 v1.2.3 → v1.2.4），最安全 -
go get -u=minor：升 minor 和 patch（如 v1.2.3 → v1.3.0），需人工验证 API 兼容性 - 不支持
-u=major，跨 major 必须手动指定@v2.0.0等
执行后务必跑一遍测试，因为即使 minor 升级也可能含破坏性变更（比如某些包把内部函数导出为公开，再删掉——虽不属语义化版本违规，但会影响反射或 mock）。
go mod tidy 不等于升级，但常被混淆
go mod tidy 只做两件事：添加缺失的依赖、删除未使用的依赖。它不会主动升级任何版本，哪怕远程已有新 patch。
典型误用场景：
- 改了
import但忘了go get，只跑tidy—— 结果报错 “package not found” - 想更新间接依赖却只执行
tidy—— 它只会按当前go.mod锁定的版本重新计算依赖图，不会刷新 - CI 中仅
tidy+build，没做版本校验 —— 可能长期卡在有漏洞的老版本上
真正要更新整个依赖树，推荐组合：
go get -u=patch && go mod tidy，再加
go list -u -m all 扫描可升级项。
复杂点在于：模块代理、replace 指令、vendor 目录三者共存时，go get 的行为会分层生效——先看 replace，再查 proxy，最后 fallback 到 vcs。这些细节不显式触发就很难察觉，尤其当 replace 指向本地 fork 且长期未同步 upstream 时。
