Dependabot 升级 PR 太多？Maven 项目先改这几个配置

Spring 项目的依赖通常由 Boot parent 或 BOM 管理，但 pom.xml 中仍可能有业务库、插件或手动指定的版本需要跟进。GitHub Dependabot 可以按计划检查依赖并提出升级 PR。配置文件必须放在默认分支的 .github/dependabot.yml；它主要管理版本更新，也可以配置部分安全更新行为。依据见 GitHub 官方配置说明。

本文写给托管在 GitHub、根目录有 Maven 构建文件的项目。配置示例依据官方文档，尚未提交到真实仓库验证；私有 Maven 仓库、企业策略和多模块目录需要单独调整。

从每周一次开始

在 .github/dependabot.yml 中写：

version: 2
updates:
  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Asia/Shanghai"
    open-pull-requests-limit: 3

package-ecosystem 指定 Maven，directory 指向构建清单所在目录；schedule 控制检查频率，不保证 PR 必定在整点出现。open-pull-requests-limit 限制同时打开的版本升级 PR 数量，安全升级 PR 不计入这个限制。具体语义见配置选项参考及减少 PR 噪音的官方指南。

真正降低噪音的审查方式

先观察两周 PR，再决定是否按依赖族分组。GitHub 的 groups 可以用 Maven 坐标模式匹配依赖，并按 major、minor、patch 更新类型分组；但把大量库合成一个 PR 后，失败时定位责任依赖也会更难。对于 Spring Boot 升级，建议保留清晰的升级记录和完整 CI，而不是只追求“PR 更少”。

依赖更新 PR 不是合并授权。至少检查：父 POM/BOM 与显式版本是否冲突、插件是否升级、测试是否覆盖关键集成、发布说明是否有破坏性变更。若使用私有仓库，还要按官方方式配置 registry 凭证，不能把 token 写进公开仓库。安全更新与普通版本更新的触发和限制不同，团队应分别制定审查时限。Dependabot 帮助发现可升级版本，真正的兼容性判断仍由构建、测试与代码审查完成。