Dependabot 依赖更新新增三天冷却：安全补丁不延迟，普通版本怎么验收

依赖更新最麻烦的地方，不是发现一个新版本，而是机器人刚提 PR，项目就被迫在没有观察窗口的情况下接住它。GitHub 最近为 Dependabot 的普通版本更新加入默认三天冷却，让发布先经过一段时间的社区反馈和项目自测；安全更新仍然即时创建，不会因为冷却而延误。

这次变化到底改变了哪一条更新路径

GitHub 在 2026 年 7 月发布的供应链安全更新中说明，Dependabot 版本更新现在默认会等依赖版本至少可用三天后，才创建普通更新 PR。这个等待窗口是给维护者留出的观察时间：如果某个上游版本很快出现恶意包、回滚或明显异常，项目不必第一时间把它带进主分支。

安全更新仍然即时进入。这是一个很重要的边界：不要把“冷却”理解成所有依赖都延迟，也不要为了追求整齐而关闭安全更新通道。普通版本解决的是变更节奏，安全版本解决的是风险暴露时间。

把三天变成可用的观察窗口

冷却本身不会替团队做判断。最小可用做法是保留默认行为，再把观察动作固定下来：每天查看 Dependabot PR 的上游版本说明、项目 issue 和 CI 失败趋势；三天后再合并普通更新。依赖数量较多时，可以用分组减少审阅噪音，但不要把互不相关的运行时、构建工具和生产 SDK 全塞进一个 PR。

version: 2
updates:
  - package-ecosystem: "go-modules"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      production-runtime:
        dependency-type: "production"
        patterns:
          - "golang.org/x/*"
          - "github.com/prometheus/*"

这段配置只表达更新范围和分组，不能替代三天后的检查。合并前至少要看 go.sum 是否只发生预期变化、核心接口测试是否通过，以及构建产物的依赖清单有没有突然增加陌生模块。

安全更新和普通更新要用两套判断尺

安全更新进入 PR 后，先确认漏洞影响的模块和实际调用路径，再安排快速回归。若漏洞只影响某个未启用的构建标签，不代表可以无条件忽略；要把判断写进 PR 说明，留下依赖版本、受影响包和测试结果。

普通更新则更适合在冷却期后看三类信号：上游仓库是否出现集中报错，版本发布说明有没有不兼容变更，项目自己的基准和集成测试是否稳定。这里别急着把“CI 绿了”当成全部结论，锁文件变化和运行时行为往往要到一条真实请求链路里才看得出来。

合并前的四项检查和失败回退

1. 检查 PR 的目标版本、发布日期和更新类型，确认它确实属于普通版本或安全更新。
2. 查看锁文件差异，重点留意间接依赖是否被整体抬升，以及是否出现 git 或远程地址来源。
3. 运行单元测试、集成测试和一次可代表生产流量的冒烟请求，记录失败包名与错误边界。
4. 准备可定位的回滚提交；如果合并后出现异常，先回退依赖版本，再单独开问题单调查上游。

如果团队有必须当天升级的内部 SDK，不建议通过关闭全部冷却来解决。更稳的方式是为该依赖设置清晰的审阅人和例外窗口，同时保留安全更新即时进入的默认路径。

相关问题

三天冷却会不会延迟高危漏洞修复？

不会。GitHub 的说明把安全更新与普通版本更新分开，安全更新仍即时创建；项目仍需尽快完成影响判断和回归。

冷却期内可以手动升级依赖吗？

可以，但这属于维护者主动变更，不应误认为 Dependabot 已经完成了观察和审阅。手动升级同样要保留版本来源、测试结果和回滚提交。

应该把所有依赖放进一个分组吗？

不建议。运行时库、构建工具和测试工具的失败半径不同，分组应围绕相近的兼容边界，避免一个小版本更新掩盖另一个大范围变化。

最后的落点

Dependabot 三天冷却的价值，是把“新版本一出现就合并”改成“先观察，再验证，再合并”。普通版本用冷却期换稳定性，安全更新保留快速通道；再配合分组、锁文件核对、CI 回归和可执行的回滚，机器人提交的 PR 才真正进入可控的发布流程。