govulncheck默认只扫描显式依赖，项目安全需结合-go test参数查间接依赖、go list人工盯包、go mod verify校验完整性及gosec/go vet代码级检查。
govulncheck 默认只扫显式依赖，不等于项目安全。真正高危的漏洞常藏在间接依赖里，比如 golang.org/x/net 被日志库悄悄拉入，但 govulncheck ./ 会跳过——除非你加 -test。
必须跑两遍 govulncheck：主代码 + 测试链路
只执行 govulncheck ./，漏掉大量测试专用依赖（如 github.com/stretchr/testify 引入的 golang.org/x/text）；而这些包在 CI 构建时仍会被下载，且可能含已知漏洞。
-
govulncheck ./：覆盖业务代码调用路径，识别直接依赖中的可触发漏洞 -
govulncheck -test ./：额外分析_test.go文件里的 import 链，暴露被忽略的 transitive 依赖 - 如果输出
"no vulnerabilities found"，别松口气——可能只是当前调用路径没进govulncheck的 callgraph 分析范围，或该漏洞尚未收录进 vuln.go.dev
手动盯包：go list -m all + 关键词过滤
govulncheck 不检查 test-only 依赖，也不保证对 golang.org/x/ 子模块全覆盖。有些包只在测试里用，但 CI 会下、proxy 可能污染、甚至已被 fork 篡改。
- 执行
go list -m all | grep -E "(golang\.org/x|github\.com/.*\.(sql|http|crypto|jwt))"，快速筛出高频风险模块 - 对每个可疑包，查它是否标记为
// indirect（go list -m -f '{{.Path}} {{.Indirect}}' 包名），再用go mod graph | grep 包名看谁引入了它 - 特别注意
golang.org/x/net和golang.org/x/text：它们被标准库周边大量依赖，但govulncheck的静态分析未必覆盖所有子功能（比如某个encoding/xml解析逻辑）
go mod verify 必须进 CI，且不能只信 go.sum
go.sum 只校验“和上次构建用的依赖一模一样”，不担保第一次引入的就是干净的。尤其当你用了 GOPROXY=fallback 或私有 proxy，中间人可能替换模块内容。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- CI 第一行就跑
go mod verify，失败直接中断；它会比对本地go.sum和 sum.golang.org 公共日志里的哈希 - 设环境变量
GOSUMDB=sum.golang.org，强制启用远程校验（旧版 Go 默认可能关掉） -
go.sum必须提交 Git，每次go mod tidy后人工确认新增条目来源——比如突然多了个github.com/xxx/yyy@v0.0.1，得查它是不是你团队维护的内部库
别漏掉 gosec 和 go vet 的安全类检查
依赖漏洞是显性风险，但硬编码密钥、不安全的 http.Redirect、unsafe 误用、路径穿越等代码级问题，govulncheck 完全不覆盖。
立即学习“go语言免费学习笔记（深入）”；
-
gosec -exclude=G104,G108 ./...（跳过部分误报项）能扫出 SQL 注入、XSS、硬编码 token 等问题 -
go vet -vettool=$(which gosec) ./...或直接集成golangci-lint，把govulncheck+gosec+go vet三者结果统一门禁 - CI 中建议用 JSON 输出解析：比如
go list -m -u -json all提取更新超 6 个月的间接依赖，自动告警
encoding/xml 解析逻辑——它既不在 govulncheck 报告里，也不在你写的代码中，只在构建时被悄悄拉进来。定期扫、及时修、管住 go.sum，才算是把基础扎住了。 
