实际生效的依赖版本由go list -m all计算得出，而非go.mod中声明的版本；它基于最小版本选择，可能因其他依赖要求而升级。
怎么看 go.mod 里实际生效的依赖版本
Go 模块的真实依赖版本不等于 go.mod 文件里写的版本号，而是由 go list -m all 计算出的“最小版本选择”结果。直接看 go.mod 容易误判，比如某依赖明明写了 v1.2.0，但因为其他模块要求更高版本，最终实际加载的是 v1.5.3。
执行以下命令查看当前构建下所有模块及其最终选用版本：
go list -m all
如果只想看直接依赖（即你项目 go.mod 中 require 块显式声明的），加 -f '{{if not .Indirect}}{{.Path}} {{.Version}}{{end}}'：
go list -m -f '{{if not .Indirect}}{{.Path}} {{.Version}}{{end}}' all
-
.Indirect为 true 表示该模块是间接依赖（被其他依赖引入），不是你主动 require 的 - 没有
-u参数时，go list显示的是当前go.sum锁定的版本，不是最新版 - 若输出中某模块路径后是
(devel)，说明它来自本地 replace，不是远程模块
怎么查某个包被谁引用了（反向依赖分析）
当你想删掉一个包，或排查为什么某个旧版本模块还在构建中出现，需要知道“谁在拉它”。Go 官方没提供原生命令，但可以用 go mod graph 配合文本处理快速定位。
立即学习“go语言免费学习笔记（深入）”；
例如，查 golang.org/x/net 被哪些模块引入：
go mod graph | grep 'golang.org/x/net' | sed 's/ / → /g'
输出类似：your-project → golang.org/x/net@v0.14.0 或 github.com/some/lib → golang.org/x/net@v0.12.0。
-
go mod graph输出是“依赖者 → 被依赖者@版本”的有向边，每行一条 - 注意区分大小写和路径拼写，
golang.org/x/net和golang.org/x/net/http2是不同模块 - 如果某模块出现在多条边中，说明多个路径都用到了它；若只出现在一行且是间接依赖，大概率可以安全升级或替换
为什么 go mod tidy 会拉进一堆没直接 import 的模块
这是 Go 模块的正常行为。go mod tidy 不仅补全你代码里 import 的包，还会补全这些包所依赖的**所有 transitive 依赖**（只要它们出现在对应模块的 go.mod 中），并写入 go.mod 的 require 块（标记为 // indirect）。
- 根本原因是 Go 构建时需确保每个模块的全部依赖都有明确版本，否则
go build可能因缺失间接依赖而失败 - 如果你删掉某个
// indirect条目再运行go build，很可能报错：找不到某个子包，比如cannot find module providing package github.com/xxx/yyy/z - 想确认某
// indirect条目是否真被用到，可临时注释它，然后运行go build ./...—— 若没报错，说明当前代码路径确实没用到它
如何识别过时、有漏洞或重复的依赖
Go 自带的 go list -u -m all 只能看“是否有新版本”，不能判断是否含已知 CVE。真正实用的组合是：
- 查更新：
go list -u -m all
（加-u才显示可用更新） - 查漏洞：
go list -u -m -json all | go run golang.org/x/vuln/cmd/govulncheck@latest
（需先go install golang.org/x/vuln/cmd/govulncheck@latest） - 查重复模块（同一路径多个版本）：
go list -m all | cut -d' ' -f1 | sort | uniq -d
—— 如果有输出，说明存在版本冲突，通常意味着某些replace或exclude没起作用
特别注意：govulncheck 默认只扫描你项目直接 import 的包，不会深入分析间接依赖的间接依赖；若要更彻底，得配合 -tests 或指定 -source。
最常被忽略的一点：go.sum 文件里的哈希校验是按模块+版本+文件内容生成的，哪怕只是 go.mod 中一个 // indirect 条目变了，go.sum 就可能新增几十行 —— 别手动删，让 go mod tidy 管理。
