go mod tidy仅同步依赖，不保障安全：它删未引用的require、补缺失indirect，但对废弃API、incompatible版本、replace分支风险、测试文件中的漏洞及间接依赖隐患均无感知，需配合govulncheck -test、golangci-lint和人工溯源验证。
直接运行 go mod tidy 不代表依赖干净——它只解决“缺失”和“冗余”，不验证“是否安全”或“是否被实际调用”。真正的自测必须分层触发三类检查：模块完整性、API 用法合规性、间接依赖风险。
go mod tidy 只做最小修复，不报潜在问题
它会删掉 go.mod 里没被引用的 require、补上缺失的 indirect 项，但对以下情况完全无感：
- 某个
indirect依赖（如golang.org/x/net@v0.22.0）内部调用了已废弃的bytes.Buffer.WriteTo，go mod tidy不会提示 -
go.mod中版本写成v1.2.3+incompatible，它不会警告兼容性风险 - 本地 replace 指向一个未提交的分支，
tidy仍认为合法，但 CI 环境可能拉不到
govulncheck 必须加 -test 才扫测试文件里的危险 API
很多不安全调用藏在 TestXXX 函数里，比如 net/http.ListenAndServe 直接监听 :8080、crypto/rand.Read 传入太小的切片、template.Parse 未过滤用户输入——这些默认不进分析范围。
- 不加
-test：只分析main和lib包的构建路径，跳过所有_test.go - 加
-test：govulncheck -test ./...才把测试文件纳入 callgraph，暴露真实调用链 - 若测试用了
//go:build integration，还得额外加-tags=integration，否则照样漏
golangci-lint 补 go vet 漏掉的 API 规范问题
go vet 能抓参数类型错、格式串不匹配，但对“API 用得不地道”基本沉默。这时候得靠 linter 组合：
- 启用
staticcheck：报time.Now().UTC()（应改用time.Now().In(time.UTC)）、strings.Replace未升级到strings.ReplaceAll - 启用
errcheck：强制检查os.OpenFile、io.Copy等返回 error 的调用，避免静默失败 - 禁用
gosimple.S1039（禁止fmt.Sprintf拼 SQL）：这是业务逻辑层约束，不是 API 层规范，开了反而干扰
查间接依赖是否含高危子包，不能只信 go list -m all
go list -m all 只输出模块名和版本，看不出谁在用哪个子包、是否真触发了问题 API。
- 先定位可疑模块：
go mod graph | grep "golang.org/x/net@"，看哪些模块引入了它 - 再确认是否在 vuln.go.dev 有编号（如
GO-2025-XXXX） - 最后人工验证调用链：
go mod why -m golang.org/x/net查谁引入，然后打开对应源码，搜WriteTo或相关函数名 - 别轻信
indirect: true标记——只要 import 链存在，运行时就可能执行，哪怕没被主模块require
最易被忽略的是：测试代码里的 API 误用和间接依赖中的传导型漏洞，这两类问题既不会让 go build 报错，也不会被 go mod tidy 修正，必须靠 -test + golangci-lint + 人工溯源三者联动才压得住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
