go list -json 不能替代审计脚本，因其仅提供构建快照，无法识别“声明未使用”或“使用未声明”问题；需结合 go mod graph（依赖边）与 go list -m（声明状态）交叉验证，并处理 import 路径归一化、build 标签、replace 和 vendor 等边界场景。
为什么 go list -json 不能直接替代自定义审计脚本
因为 go list -json 输出的是构建视角的依赖快照（含隐式 indirect 依赖），但审计需要识别「被显式声明却未被使用」或「被使用却未被声明」的模块——这要求同时比对 go.mod 声明、源码 import 语句、以及实际构建图。纯 go list 不提供 import 行号、未使用声明标记，也无法区分 // indirect 是 Go 工具自动添加还是人为保留。
如何用 go mod graph + go list 搭建基础审计流水线
核心思路：用 go mod graph 获取所有解析出的依赖边（A → B），再用 go list -m -f '{{.Path}} {{.Indirect}}' all 获取模块声明状态，最后交叉验证。
- 先运行
go mod graph | grep 'your-module-name'看哪些模块被你的代码（或其依赖）直接拉入 - 再执行
go list -m -f '{{.Path}} {{.Indirect}}' all | grep 'true$'找出所有标记为indirect的模块 - 把两者取差集：如果某模块在 graph 中出现、但在
go list -m中未声明（即不在go.mod的require区块里），说明它被间接引入但可能已被上游移除兼容性——这时go mod tidy会报错 - 注意
go list -m all包含std和cmd，审计时应过滤掉：加| grep -v '^std$' | grep -v '^cmd$'
怎么检测 import 语句与 go.mod 声明不一致
Go 没有官方 AST 导出工具链供脚本调用，但可借助 golang.org/x/tools/go/packages 库安全加载包并遍历 import 路径。关键不是“有没有 import”，而是“import 的路径是否在 go.mod 中有对应 require 条目（或其传递闭包中存在）”。
- 用
packages.Load加载当前模块全部./...包，设置Mode: packages.NeedImports - 遍历每个
*Package的Pkg.Importsmap，提取键（即 import path） - 对每个 import path，检查它是否满足：① 是标准库；② 在
go list -m -json all输出的模块列表中存在；③ 或属于本地 replace 路径（需额外解析go.mod的replace区块） - 容易踩的坑：
gopkg.in/yaml.v2这类带版本后缀的路径，在go.mod中可能写成gopkg.in/yaml.v2 v2.4.0，但 import 语句里是gopkg.in/yaml.v2——匹配时要忽略版本号后缀
审计脚本必须处理的三个边界场景
真实项目里，以下情况会让简单正则或字符串匹配彻底失效：
-
//go:build或// +build标签导致某些文件在特定 GOOS/GOARCH 下才参与构建，其 import 不一定出现在默认go list结果中——审计时需指定-tags参数重跑 - replace 指向本地路径（如
replace example.com/foo => ../foo）时，go list -m仍显示原路径，但实际加载的是本地目录，此时 import 审计必须同步解析go.mod的 replace 规则并做路径映射 - vendor 目录启用时（
GOFLAGS=-mod=vendor），go list输出的模块版本可能和go.mod不一致，脚本若只读go.mod就会误判——应优先以go list实际输出为准
复杂点永远在模块路径归一化和构建上下文切换上，不是写个 for 循环就能覆盖的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
