govulncheck ./ 扫描实际调用链上的 cve，结合 go list -m -u -json all 定期检测过时依赖，并通过 github actions 自动执行、失败阻断、覆盖全路径，配合 dependabot 启用 beta 生态与 lockfile-only 策略，辅以 go build -a -v 和 go test -race ./... 验证升级安全性。

go list -m -u all 是检查过时依赖的起点，但不是全部

它能列出所有模块当前版本和可升级版本，比如 github.com/gorilla/mux v1.8.0 [v1.9.0]，但只告诉你“有新版本”，不告诉你这个模块是否被实际使用、是否在关键路径上、升级后会不会破坏 http.Handler 实现逻辑。漏掉 -u 参数会导致完全看不到更新项；而只跑一次命令，也解决不了“定期”这件事。

用 GitHub Actions 跑 govulncheck + go list -m -u，比手动更可靠

CI 中执行这两条命令，才是真正在生产环境落地的定期检测方式：

• govulncheck ./ 扫描实际调用链上的 CVE，比单纯看版本号更有意义
• go list -m -u -json all 输出结构化数据，方便脚本提取超过 6 个月未更新的间接依赖（比如 golang.org/x/net 被某个测试工具间接引入，长期停更却没人注意）
• 必须加 || exit 1 让构建失败——否则报告只是日志里一闪而过的文字
• 别只扫 ./，要覆盖 ./... 和 ./internal/...，否则漏掉内部包里的 import

Dependabot 能自动发 PR，但默认配置容易忽略间接依赖

GitHub 原生 Dependabot 默认只监控 go.mod 中显式 require 的模块，对 indirect 依赖静默处理。这意味着：一个被三个不同库共同拉进来的 github.com/go-yaml/yaml，即使已有高危 CVE，也不会触发 PR。

Golang Lint

Golang 项目 lint 最佳实践与 golangci‑lint 配置——运行 linter、编辑 .golangci.yml、使用 nolint指令抑制警告。

下载

要让它生效，得在 .github/dependabot.yml 里显式打开：

• enable-beta-ecosystems: true（启用实验性生态支持）
• versioning-strategy: lockfile-only（强制基于 go.sum 分析，而非仅看 go.mod）
• 配合 schedule.interval: daily，避免每周一集中爆炸式 PR

自动升级 ≠ 自动验证，go build -a -v 是最后一道防线

无论 Dependabot 还是 Renovate，都只改 go.mod 和 go.sum，不运行任何代码。真正决定升级是否安全的，是本地或 CI 中那一行 go build -a -v。

• -a 强制重编译所有依赖，暴露隐藏的类型不兼容（比如某库升级后把 func Serve() 改成 func ServeHTTP()）
• -v 输出详细构建路径，能快速定位是哪个 indirect 模块导致 crypto/tls 冲突
• 别跳过测试：加 go test -race ./...，很多并发 bug 只在升级后才浮现

最常被跳过的环节，是没在升级后验证 vendor 目录是否同步更新——go mod vendor 必须紧跟 go mod tidy，否则 go build -mod=vendor 仍会悄悄联网拉旧版。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！