GitHub Dependabot 默认三天冷却窗口上线后：依赖安全修复如何安排发布节奏

Dependabot 的更新节奏最近多了一个容易被忽略的默认值：普通版本更新要等新版本在注册表里放满三天，才会创建 version update 拉取请求。这个等待只针对版本更新，安全更新仍然可以立即进入修复流程，所以它不是把漏洞修复也一起“延后”。

三天冷却到底改变了哪一类 Dependabot 请求

GitHub 在 2026 年 7 月的 Changelog 中说明，Dependabot 现在默认等一个新版本在对应注册表中存在至少三天，再为它创建版本更新 PR。这个变化针对的是“把依赖从旧版本升到新版本”的日常维护请求。

安全更新是另一条路径。依赖被 GitHub 标记为存在可修复漏洞时，security update 不受默认冷却影响，团队仍应按漏洞优先级处理。这里别把“没有收到普通升级 PR”和“没有安全问题”画等号。

先准备一份能解释“没开 PR”的配置

Dependabot 的配置入口仍是仓库里的 .github/dependabot.yml。最小配置至少需要生态、目录和更新频率；冷却窗口是建立在这条检查计划之上的第二个判断。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 3

这段配置不需要重复写三天，因为 GitHub 已把三天作为默认行为；显式写出来的价值在于让仓库维护者读配置时一眼看到团队的意图。若项目后续希望按升级幅度区分风险，可以把默认值拆成不同级别。

把等待天数分给 major、minor 和 patch

官方配置支持 semver-major-days、semver-minor-days 和 semver-patch-days。例如，生产服务可以给 major 更长的观察期，让 patch 更快进入测试：

cooldown:
  default-days: 5
  semver-major-days: 30
  semver-minor-days: 7
  semver-patch-days: 3

配置的含义是“什么时候允许 Dependabot 产生版本更新请求”，不是“什么时候允许直接合并”。合并前仍要看变更日志、锁文件差异、CI 结果和真实业务回归。

运行检查时，按三个时间点定位延迟

一看注册表里的发布时间

新版本刚发布一小时，没有 PR 可能是正常现象。先记下包管理器看到的发布时间，再与三天窗口比较。不要只看 Dependabot 最近一次运行时间。

二看 schedule.interval

冷却结束也不等于立刻开 PR。Dependabot 还要等到仓库配置的 daily、weekly 或其他计划运行。若团队配置了每周检查，实际等待时间会是冷却窗口和下一次计划之间的较大值。

三看它是不是 security update

如果是漏洞修复请求，不能用 cooldown 解释延迟。应转去检查 GitHub 的 Dependabot alerts、依赖清单、仓库权限和 CI 失败原因，确认是不是更新路径或构建链路出了问题。

用 include、exclude 控制例外，而不是全仓库放开

当只有少数依赖需要更长观察期时，可以用 include 指定范围，再用 exclude 明确例外。官方文档说明，exclude 优先级高于 include；两边同时出现时，该依赖不会套用冷却。

cooldown:
  default-days: 5
  include:
    - "requests"
    - "numpy"
    - "pandas*"
  exclude:
    - "pandas"

这类配置适合把高变更风险的依赖留在观察名单里，但不建议用通配符堆出一张没人能维护的例外表。每个例外都应该能说清楚：它为什么要更快，谁负责看 CI 和发布结果。

把三天变成一次人工审查窗口

冷却窗口最有价值的动作不是等待，而是降低“刚发布就自动进入代码库”的速度。维护者可以在这段时间查看上游 release notes、漏洞公告、包下载异常和项目自己的回归测试；若版本很快被撤回，团队也不必先处理一批已经打开的升级 PR。

但它挡不住已经存在于旧版本的风险，也不能判断业务是否兼容。对关键依赖，建议把 Dependabot PR 接入完整 CI，并在合并前检查锁文件、启动日志和核心接口的 smoke test。

相关问题

三天 cooldown 会延迟漏洞修复吗？

默认不会。它针对 version updates，security updates 不受这项默认冷却影响。

为什么三天后仍然没有 Dependabot PR？

还要检查 schedule.interval、依赖生态是否支持该配置、版本约束是否允许升级，以及仓库是否暂停了更新。

可以完全关闭 cooldown 吗？

可以通过 cooldown 配置调整窗口或选择退出，但关闭后仍应保留代码审查和 CI 门禁。

patch 更新一定只等三天吗？

三天是默认值；如果配置了按 SemVer 级别的天数，patch 会使用对应的 semver-patch-days。

最后的维护判断

Dependabot 的默认三天窗口适合给普通版本更新留出观察时间，同时把安全更新保留在快速通道。落地时把它当作发布流程中的一道时间门，而不是安全结论：等待结束后仍要看变更、跑测试、审 PR，发现异常则暂停合并并回到上游公告核对。