不能，go get -u 默认只更新直接依赖，不递归更新间接依赖（子模块），也无法按名称批量更新指定子模块；精准更新需先使目标模块成为直接依赖（如 go get golang.org/x/net@latest），再执行 go mod tidy。
go get -u 能否批量更新子模块？
不能直接批量更新“指定的子模块”。go get -u 默认只升级当前模块的直接依赖（go.mod 中的 require 行），不会递归更新间接依赖（即子模块的依赖），更无法按名称筛选并更新某几个特定子模块。
常见错误现象是：执行 go get -u github.com/some/lib 后，发现该库的子依赖（比如 github.com/some/lib/v2 或它用到的 golang.org/x/net）没变——因为 go get 不会主动触碰这些。
- 真正生效的是
go.mod里显式声明的模块路径，不是 import 路径或嵌套路径 -
go get -u ./...会尝试更新所有本地包的依赖，但仍是基于当前模块的 require 规则，不等于“批量更新子模块” - 如果某个子模块被多个依赖共同引用，它的版本由
go mod tidy根据最小版本选择（MVS）决定，手动干预需谨慎
如何精准更新某个子模块（如 golang.org/x/net）？
必须让该模块出现在当前项目的 go.mod 的 require 列表中——哪怕它只是间接依赖。Go 不允许直接升级未声明的模块。
实操分两步：
- 先用
go get golang.org/x/net@latest（或指定 commit/tag）——这会把它加进require，并触发go mod tidy自动调整其他依赖以满足兼容性 - 若只想升版本不改主版本号，用
go get golang.org/x/net@v0.25.0；若要强制覆盖已有约束，加-d参数跳过构建检查（仅用于调试） - 注意：如果该模块已被更高版本间接引入（比如通过
golang.org/x/crypto），go get可能拒绝降级，此时需配合replace或先go mod graph | grep查清来源
批量更新多个指定模块的可靠做法
没有单命令批量更新任意子模块，但可通过脚本+go get 组合实现。关键是把目标模块路径列出来，逐个执行，再统一 tidy。
例如想同时更新 golang.org/x/text、golang.org/x/sys 和 github.com/go-sql-driver/mysql：
go get golang.org/x/text@latest \
golang.org/x/sys@latest \
github.com/go-sql-driver/mysql@v1.7.1
这条命令本质是并发执行多个 go get，效果等同于分别调用，且最终自动运行 go mod tidy。
- 不要用空格分隔多个
@版本（如mod@v1 mod@v2），Go 不支持 - 若其中某个模块有主版本号（如
github.com/gorilla/mux/v2），必须带/v2，否则会拉取 v0/v1 分支 - 执行后检查
go.mod是否新增了这些模块的require行；若没出现，说明它们仍只是间接依赖，此时go get实际没起效
为什么 go mod edit -replace 不适合“更新”？
go mod edit -replace 是硬性替换路径，不是升级版本。它绕过版本解析逻辑，常用于本地开发调试，但会破坏依赖可重现性，且不解决真实版本冲突。
典型误用场景：
- 用
go mod edit -replace golang.org/x/net=../x/net想“更新”，结果 CI 构建失败——因为 replace 不会被go mod vendor包含，也不影响其他模块对 net 的版本选择 - replace 后执行
go mod tidy，Go 仍可能把 replace 移除，因为它优先采用require中声明的版本 - 真正需要“更新”的场景，应优先走
go get+ 显式 require，而非 replace
间接依赖的版本最终由 MVS 算法决定，手动干预的前提是让它变成直接依赖——这点最容易被忽略。
