go list -m -u all 是判断依赖是否陈旧的第一道筛子，它只读取 go.mod 并查询模块索引，输出所有依赖及其可升级的最新版本，带方括号（如 [v1.13.0]）表示存在更新，无括号不等于安全，需结合 pkg.go.dev 等人工验证。
用 go list -m -u all 快速识别过时依赖
这个命令是判断依赖“是否陈旧”的第一道筛子。它不下载、不修改，只读取 go.mod 并查询模块索引，输出当前所有依赖及其可升级到的最新版本。
常见错误现象：把 go list -u ./...（包路径模式）误当成模块更新检查——它只查本地包，完全不涉及远程版本信息。
-
-m表示模块层级，必须加；-u表示查找可用更新；all表示包含间接依赖 - 输出中带方括号的才是可更新项，例如
github.com/sirupsen/logrus v1.9.0 [v1.13.0]，括号外是当前锁定版本，括号内是最新 patch/minor 版本 - 没有方括号 ≠ 安全，可能只是该模块在当前主版本下已无更新，但作者早已弃坑（需人工查 pkg.go.dev 的 Last updated 时间）
用 govulncheck ./ 精准定位实际调用链上的 CVE
别只扫 go.sum 或依赖列表——govulncheck 是 Go 官方唯一能做“调用路径敏感”漏洞分析的工具，它只报你代码里真正在用、且被调用到的函数所暴露的漏洞。
容易踩的坑：在 CI 中执行 govulncheck ./...（带子目录）会漏掉主模块未显式 import 的间接依赖漏洞；必须用 ./ 才覆盖整个 module 树。
- Go 1.21+ 内置，无需安装；旧版运行
go install golang.org/x/vuln/cmd/govulncheck@latest - 输出含
CVE-XXXX-XXXX编号、影响的具体函数（如encoding/xml.Unmarshal）、修复建议版本 - 若报告某漏洞“not used”，说明你的代码没走到那条路径，可暂不升级——这是它比单纯查 NVD 数据库强的关键
用 go mod graph 和 go mod why 定位“甩不掉”的坏依赖
当你发现某个可疑模块（比如一个两年没更新、stars 极少的 fork 包）出现在 go list -m -u all 输出里，得立刻查清：它是谁拉进来的？能不能干掉？
典型场景：升级 golang.org/x/net 后，go list 显示它仍卡在旧版，但你代码里根本没直接 import 它——说明是某个中间依赖硬绑定了它。
-
go mod graph | grep 'unmaintained/pkg'查谁引入了它 -
go mod why -m github.com/bad/pkg输出从 main 到它的完整 import 路径，精确到哪一行import - 如果路径终点是某个你控制的依赖（如
github.com/your-org/legacy-lib），优先改那个库；如果是第三方，考虑替换或提 PR
为什么不能只靠 go.sum 校验就认为依赖健康？
go.sum 只保证下载内容未被篡改，不保证逻辑安全。一个 checksum 完全合法的模块，可能含已知 CVE、无限循环 bug、或作者故意埋的后门（如 2022 年 colors 包事件）。
更隐蔽的风险在于：MVS（最小版本选择）机制会让 go build 自动降级满足约束的旧版模块，而你 go.mod 里写的 require 可能根本没生效。
- 运行
go list -m all对比go.mod中的require，看哪些版本被 MVS 覆盖了 - 对关键模块（如
crypto/tls,net/http相关），在go.mod中显式写死最小版本，例如require golang.org/x/crypto v0.17.0 -
GOINSECURE或replace指令会绕过go.sum校验，CI 中必须禁止这些配置上线
encoding/xml 解析逻辑——它既不在你的 import 列表里，也不在 govulncheck 的默认扫描范围内，除非你主动用 go mod graph 抽丝剥茧。
