go list -m -u all是最接近“自动检测更新”的官方方式，它不修改代码或下载包，仅列出当前版本及可升级到的最新语义化版本，需在含go.mod的根目录运行，输出中带方括号（如[v1.9.0]）表示可升级。
Go 没有“自动检测工具”这个独立组件，所有依赖分析能力都内置于 go 命令中——你不需要装额外工具，但必须知道哪几个命令组合起来才能真正“自动检测”。
用 go list -m -u all 检查哪些依赖能升级
这是最接近“自动检测更新”的官方方式，它不改代码、不下载包，只告诉你当前用了什么版本、最新能升到什么版本。
- 必须在含
go.mod的项目根目录下运行，否则报错no modules found - 输出中带方括号的才是可升级项，比如
github.com/sirupsen/logrus v1.8.1 [v1.9.0]；没括号说明已是该主版本下最新 - 它只查语义化版本（
v1.x.x）和伪版本（v0.0.0-2023...），但不会提示replace或exclude后实际生效的版本 - 注意：它不区分直接依赖和间接依赖，所有出现在
go.mod里的模块都会列出来，包括// indirect标记的
用 go mod graph 发现重复引入或冲突版本
当 go list -m -u all 显示某个包有两个不同版本（如 v1.8.1 和 v1.9.0），就得靠 go mod graph 看清谁拉进来的。
- 每行格式是
[依赖者] [被依赖者@版本]，例如myapp github.com/gin-gonic/gin@v1.9.0 - 如果发现同一包多个版本，比如
golang.org/x/net@v0.14.0和@v0.17.0同时存在，说明不同上游模块各自锁了不同版本 - 配合
grep快速定位：想查谁用了旧版x/net，就跑go mod graph | grep 'golang.org/x/net@v0.14.0' - 注意：输出不含
indirect标记，也不体现replace后的实际路径，得手动对照go.mod文件确认
用 go mod why 追查陌生依赖的来源
当你在 go list -m all 或 go mod graph 里看到一个完全没主动 import 的模块（比如 rsc.io/quote），go mod why 是唯一能说清“它怎么进来的”的命令。
立即学习“go语言免费学习笔记（深入）”；
- 语法是
go mod why -m example.com/pkg，它会从主模块出发，沿着 import 链往上找，给出最短路径 - 如果输出是
(main module)，说明这个包被你的代码直接 import 了；如果是github.com/foo/bar，那就是它带进来的 - 它不处理条件编译（如
// +build ignore）或运行时动态加载，只看静态 import 语句 - 常见坑：路径写错会返回
unknown module，必须和go list -m all输出的模块名完全一致（包括大小写和斜杠方向）
真正容易被忽略的是：这些命令之间不是孤立的。比如发现一个高危模块，光靠 go mod graph 知道谁引用了它，但不知道是否真被用到；这时得补一句 go mod why -m xxx 确认调用链是否可达。没有单点“全自动”方案，只有命令组合形成的检测闭环。
