不能，go list -m all 仅输出扁平化模块列表，不体现依赖层级、引入路径、版本冲突或 replace/exclude 实际生效效果，需组合 go mod graph、go mod why -m、gomodtree 等命令才能完整分析。
直接用 go list -m all 就能看到当前项目实际解析出的所有模块和版本，但它是扁平列表，不体现层级；真要看清谁依赖谁、哪个版本被谁拉进来，得组合几个命令，不能只靠一个。
查当前项目所有依赖模块及版本（含伪版本）
运行 go list -m all 是最基础的入口。它会触发模块图构建，输出包括直接依赖、间接依赖、replace 后的 (devel) 标记，以及未打 tag 的伪版本（如 v0.0.0-20241001123456-abcdef123456）。
- 如果只想看显式 require 的模块，过滤掉带
+incompatible和伪版本的行，再跟go.mod里的require块比对更可靠 -
go list -m -f '{{.Path}} {{.Version}}'可定制输出格式，但all模式必须带上，否则只返回当前 module 本身 - 注意：
go list -m all不反映replace或exclude在构建时的真实加载路径，它展示的是模块解析结果，不是运行时导入路径
查某个包在编译时实际加载的模块和版本
用 go list -f '{{.ImportPath}} {{.Module.Path}} {{.Module.Version}}' ，这才是最贴近运行时视角的查询方式。
-
github.com/sirupsen/logrus，不能写成logrus - 对标准库（如
net/http），.Module字段为空，.Version为""，此时版本由 Go 工具链决定 - 如果该 import path 被
replace或exclude影响，结果会如实体现——比如replace github.com/foo/bar => ./local后，.Module.Path仍为github.com/foo/bar，但.Module.Version显示(devel)
查某模块为何出现在依赖中（定位“幽灵依赖”）
当你在 go list -m all 里看到一个陌生模块，又不确定谁把它拉进来的，就用 go mod why -m 。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 它只给出一条最短路径（例如
main → github.com/spf13/cobra → gopkg.in/yaml.v2），不是全路径集合 - 对本地 replace 路径（如
./fix）无效，得查原始模块名，比如go mod why -m github.com/xxx/yyy - 它不保证覆盖所有引用路径——如果某模块被多个上级以不同版本引入，需配合
go mod graph | grep手动比对
查某个模块有哪些可用版本（不依赖当前项目）
运行 go list -m -versions ，它绕过 go.mod，直接查配置的 proxy（默认 proxy.golang.org）或本地缓存。
- 返回的是 tagged 版本 + pseudo-version，比如
v1.9.1、v0.0.0-20240901000000-123456789abc - 若
GO_PROXY=off或网络不通，会报错no matching versions for query "latest" - 这个命令的结果不表示当前项目用了哪些版本，仅说明“可获取”，要确认是否真被使用，还得回看
go list -m all或go mod graph
真正容易被忽略的是：Go 没有“已安装包”的全局概念，所有版本信息都绑定在模块缓存、go.sum 和当前 go.mod 的上下文中；replace 和 exclude 的行为在不同命令里表现不一致，比如 go mod graph 完全无视它们，而 go list -f 会体现 (devel) 状态——查依赖前，先想清楚你问的是“模块解析结果”，还是“构建时实际加载路径”，或是“proxy 上有哪些版本”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
