根本原因是当前目录不在module根下或目标模块未被解析进构建图，go list -m仅读go.mod和本地缓存，不下载不补全，未import的模块即使出现在replace/exclude中也不会输出。
go list -m 为什么加了 -f 还是空输出
根本原因不是模板写错，而是当前目录没在 module 根下，或目标模块根本没被解析进构建图。go list -m 只读 go.mod 和本地缓存，不下载、不补全——如果某个模块只出现在 replace 或 exclude 里但没被任何 .go 文件 import，它就不会出现在 go list -m all 结果中。
实操建议：
- 先确认在含
go.mod的目录执行，用go list -m看是否至少输出当前模块路径 - 查第三方模块前，确保它已被
go mod download或至少出现在go.sum中；否则会报 “no matching versions” -
-f模板里用{{.Path}}而非{{.ImportPath}}——后者属于包层级字段，-m下不存在 - 避免写
go list -m -f '{{.Path}}' .：点号.是包路径语法，-m不认；该场景必须用all或具体模块路径如golang.org/x/net
怎么只列出真正被代码引用的直接依赖
很多人以为 go list -m -f '{{if not .Indirect}}{{.Path}}{{end}}' all 就是“实际用到的依赖”，其实不是——它只过滤掉间接引入标记，但无法区分某个模块是否真被 import 过。比如 github.com/sirupsen/logrus 在 go.mod 里是 direct require，但所有 .go 文件都没 import 它，它依然会被列出来。
更靠谱的做法是交叉验证：
立即学习“go语言免费学习笔记（深入）”；
- 先跑
go list -f '{{.ImportPath}}' ./...获取所有本地包实际 import 的路径（注意三点号...包含子目录） - 再跑
go list -m -f '{{if not .Indirect}}{{.Path}}{{end}}' all得到 direct 模块列表 - 取两者差集：那些出现在后者但不在前者里的模块，才是疑似未使用的“幽灵依赖”
- 别漏掉测试文件：
go list -f '{{.ImportPath}}' ./... | grep '_test$'单独检查测试专用 import
go list -json 和 -f 输出的区别在哪
-json 是稳定结构化输出，字段名和嵌套关系由 Go 工具链保证向后兼容；-f 是模板引擎，字段存在性取决于上下文——比如 .Replace 字段只在模块被 replace 时才出现，.Version 在未下载模块时为空字符串，而 .Indirect 在 -m 下恒有值但在包层级下不存在。
选哪个取决于用途：
- 写脚本解析依赖关系？必须用
-json，例如go list -m -json all | jq -r '.Path + " " + (.Version // "unknown")' - 快速人眼扫一遍？
-f更灵活，比如go list -m -f '{{.Path}} {{with .Replace}}{{.Path}}→{{.Version}}{{end}}' all能一并显示 replace 映射 - 查某模块是否被 replace？
-json输出里看"Replace": null还是{"Path": "...", "Version": "..."}，比-f判断更可靠 -
-json不支持条件判断（如{{if .Indirect}}），想做逻辑过滤只能靠外部工具（jq/grep/sed）
为什么 go list -m -u all 有时卡住或超时
-u 参数会触发网络请求，挨个查每个模块在 proxy 上的最新版本。如果某个模块域名不可达、proxy 配置异常、或模块已归档（如旧版 rsc.io/quote），就会阻塞甚至超时——这不是命令 bug，而是设计使然。
规避方法：
- 加
-timeout=5s限制单个请求时间：go list -m -u -timeout=5s all - 跳过已知不可达模块：用
go list -m -f '{{if not .Indirect}}{{.Path}}{{end}}' all | xargs -I{} sh -c 'go list -m -u {} 2>/dev/null || true' - 离线环境完全禁用网络：设
GOPROXY=off再运行，此时-u会静默跳过所有远程查询，只返回本地缓存信息 - 注意
-u不等于 “可升级”：它只查 latest tag，不校验是否满足require的版本约束；真正能go get -u成功的，还得看 MVS 规则是否允许升版
go list 的边界——它只反映静态声明和已缓存状态，不运行代码、不模拟构建、也不猜测意图。任何依赖分析结论，都得配合 go mod why、go mod graph 或实际 go build -a -v 验证才算闭环。 
