go get -u 默认升级到最新 minor 版本，即在同一主版本内升至最新次版本和修订版本组合，如 v1.2.3 → v1.5.0；它不跨主版本，是 Go 的设计行为而非 bug。
go get -u 默认升级到最新 minor 版本
执行 go get -u 时，Go 不会跨主版本（如 v1 → v2），但会在同一主版本内升到**最新的次版本（MINOR）和修订版本（PATCH）组合**。例如当前依赖 github.com/some/lib v1.2.3，运行后可能变成 v1.5.0（只要 v1.5.0 满足所有依赖约束）。这不是 bug，是 Go 的设计行为——-u 就是为“向上兼容地更新”服务的。
用 go list -m -u=patch + go get 组合精准控制
如果只想升 PATCH（比如 v1.2.3 → v1.2.4），但又怕 go get -u=patch 被间接依赖带偏（比如某个依赖 require v1.3.0，导致 MVS 仍选 v1.3.0），推荐分两步走：
- 先查哪些模块有可用的 patch 升级：
go list -m -u=patch all - 再对目标模块显式拉取：
go get github.com/some/lib@v1.2.4（注意带@） - 最后运行
go mod tidy清理冗余依赖并更新go.sum
这个流程绕过了 MVS 的全局决策，直接锁定版本，适合 CI 脚本或发布前检查。
写脚本批量更新指定模块的 minor 版本
下面是一个 Bash 片段，用于遍历 go.mod 中所有非主版本升级的 direct 依赖，并尝试升到最新 minor：
立即学习“go语言免费学习笔记（深入）”；
#!/bin/bash
# 只处理 v1.x.y、v2.x.y 等形式（排除 v0.x 和 pseudo-version）
go list -m -f '{{if and (not .Indirect) (ne .Version "none")}}{{.Path}} {{.Version}}{{end}}' all | \
while read path ver; do
if [[ $ver =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
major=$(echo $ver | cut -d. -f1)
# 获取该主版本下最新 minor（不跨 major）
latest=$(go list -m -f '{{.Version}}' "$path@latest" 2>/dev/null | grep "^$major\.[0-9]\+\.[0-9]\+$" | head -n1)
if [[ -n "$latest" && "$latest" != "$ver" ]]; then
echo "upgrading $path from $ver to $latest"
go get "$path@$latest" && go mod tidy
fi
fi
done
关键点：
- 它跳过
v0.x和伪版本（v0.0.0-...），因为这些不遵循 SemVer 兼容性承诺 - 不依赖
go get -u的全局行为，而是逐个go get $path@$latest，避免间接依赖干扰 - 每次
go get后立即go mod tidy，防止go.sum残留旧哈希导致 CI 失败
容易被忽略的坑：replace 和 exclude 会让脚本失效
如果你的 go.mod 里有 replace 或 exclude，上面脚本查到的 latest 可能不是真实可拉取的版本。比如：
-
replace github.com/some/lib => ./local-fix：脚本仍会去远程查@latest，但实际构建用的是本地路径，版本号已无意义 -
exclude github.com/some/lib v1.4.0：即使v1.4.0是最新 minor，MVS 也会跳过它；脚本若没检查exclude列表，就会误判
真正可靠的自动化更新，必须先解析 go.mod 内容，过滤掉被 replace 或 exclude 干扰的模块——这已经超出一行命令范畴，得用 go mod edit -json 或专用工具（如 gomod）来处理。
