go list -json -m all 能准确提取完整模块依赖树，它触发模块图计算，输出去重且已解析的全部模块，包括间接依赖和实际加载项，比直接解析 go.mod 更可靠。
用 go list -json 提取模块依赖树
直接解析 go.mod 只能得到直接依赖，漏掉间接依赖（require 里带 // indirect 的）和构建时实际加载的模块。真正反映运行时依赖的是 go list -json -m all ——它会触发模块图计算，输出完整、去重、已解析的模块列表。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在模块根目录下执行，确保
GO111MODULE=on（Go 1.16+ 默认开启，但 CI 环境可能关闭） - 加
-mod=readonly避免意外修改go.mod或下载新版本 - 输出是 JSON 流（每行一个 JSON 对象），适合用
jq处理，例如：go list -json -m -mod=readonly all | jq -r '.Path + " " + .Version'
批量检测缺失/不一致的 go.sum 条目
go.sum 缺失会导致 go build 或 go test 失败，错误信息通常是：verifying github.com/xxx@v1.2.3: checksum mismatch 或 missing go.sum entry。但手动核对效率低，且容易忽略子模块。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go mod verify检查所有模块校验和是否匹配本地缓存，失败时返回非零码 - 更彻底的做法是清空模块缓存后重拉：
go clean -modcache && go mod download && go mod verify
（注意：这会触发网络请求，CI 中需确保网络可达） - 若只想检查是否缺失（不验证内容），可用
go list -m -f '{{if not .Indirect}}{{.Path}} {{.Version}}{{end}}' all | xargs -r -n1 go mod download，再看是否报错
识别未使用的直接依赖（可安全移除的 require）
很多项目长期迭代后，go.mod 里残留着不再被任何源码 import 的模块。这些“幽灵依赖”会拖慢 go mod tidy、增加安全扫描噪声。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
go mod graph输出所有 import 关系，但太冗长；更实用的是先运行go mod tidy -v，观察控制台输出哪些模块被“dropped” - 确认无误后，用
go mod edit -droprequire=github.com/xxx/yyy逐个移除（Go 1.17+ 支持） - 注意：某些模块虽无 import，但被
//go:embed、//go:generate或构建 tag 间接使用，需人工确认
用 Bash 脚本串联并捕获关键异常
单条命令好记，批量检测要防静默失败。比如 go list 出错时不会中断后续步骤，导致误判“全部正常”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 脚本开头加
set -euo pipefail，让任意命令失败立即退出 - 把关键检查封装成函数，例如：
check_sum() { echo "→ checking go.sum..."; go mod verify >/dev/null; } - 对多模块仓库（含多个
go.mod），用find . -name 'go.mod' -execdir bash -c 'echo "$PWD"; go mod verify' \;遍历
最易被忽略的是 Go 版本兼容性：不同 Go 小版本对 go.sum 格式、indirect 标记逻辑有差异。同一份脚本在 Go 1.19 和 1.22 下可能给出不同结论。别只信本地结果，CI 中务必指定 GOPATH 和 GOROOT 并复现目标环境。
