依赖更新冷却期：为什么等 7 天更安全

最会把线上弄疼的改动，很多时候不是“大重构”，而是那种 PR 标题看着特别无害的：chore: bump dependencies。CI 绿得发亮，review 也很快过了，结果上线后开始出现那种最烦的“半残”：登录偶发失败、日志格式悄悄变了、缓存命中率掉了一截。

真正恶心的点在于：你第一反应通常不会怀疑“依赖”。你会先怀疑业务代码、环境变量、某个看起来更“像凶手”的改动。绕一圈回来才发现，罪魁祸首只是一个昨天刚发的新版本。

所以我现在更信一件事：依赖升级风险最高的，往往不是“太旧”，而是“太新”。冷却期不是玄学，是把等待变成流程。

依赖更新为什么需要“冷却期”？

冷却期的作用只有一个：用时间换确定性，把“第一波真实用户的坑”尽量留在你系统之外。

官方说法其实很直白：Renovate 提供了 minimumReleaseAge 这种配置项，让你可以“新版本发布后至少等一段时间再提 PR / 再允许合并”。（出处：Renovate 配置文档，见文末链接）

你可以把依赖更新想成买装修材料：刚出厂时参数都很好看，但真正能不能上墙，是看它进了真实工地之后，会不会开裂、掉色、返工。软件依赖也一样——刚发布的版本同时有三类不确定性：

• 维护者自己还没踩完边界 case
• 社区还没来得及报兼容性问题
• 你的上游依赖、构建工具、运行环境未必同步适配

最坑的是：这些问题很多 CI 不一定测得出来。因为你的测试覆盖的是“你以为重要的路径”，线上打你的，往往是“你没想到会被影响的路径”。

这里的核心洞察是：安全漏洞风险，和“刚发布版本的不稳定风险”，本来就是两类风险。你不该用一个节奏处理所有依赖。

自包含回答块（可被摘录）：
依赖冷却期=为新版本设置「发布后等待 N 天再合并」的规则：安全修复走快速通道，普通 patch/minor 等社区验证，major 必走人工审查+金丝雀+可回滚。这样既不拖漏洞修复，也减少新版本翻车。

冷却期的默认分级策略（那张你可以直接截图的表）

7 天是个很好用的默认值，但它不该“一刀切”。我更推荐按更新类型分层，再对基础库单独提级。

我不敢说这表适合所有团队，但它有个很现实的好处：你不用再在“怕有漏洞”和“怕上新炸”之间来回拉扯。因为这两件事被你拆成了两条不同的流水线。

呼吸点：版本号这东西很多时候只是“礼貌性遵守语义化版本（SemVer）”。你以为 patch 只补洞，它可能顺手改了默认行为。交过几次学费后，我现在看到“just a patch”，都会多瞄两眼。

把冷却期做成可控流程：等待 + 闸门 + 金丝雀 + 回滚

只配冷却期还不够。冷却期只能帮你避开“刚发布的不稳定”，避不开“它就是跟你系统不兼容”。真正能落地的，是把它接到合并与发布链路里。

你可以把整条链路想成开车上高速：

• 冷却期：出发前先看路况，别抢第一批上路
• 合并闸门：收费站（不满足条件就别上高速）
• 金丝雀：先跑一小段试车，别一脚油门全量
• 回滚：车坏了有应急车道，不用原地开会

闸门 1：锁文件审查（别只盯 package.json）

很多依赖事故，问题不在你主动升的那个包，而在 lockfile 里连带带出来的几层间接依赖。review 时我一般会先看“diff 是否可解释”：

• lockfile 改动是不是异常大（比如标题写 “bump one package”，结果改了几百行）
• 有没有新增 install/postinstall 脚本
• 同一个 PR 里是不是顺手升级了一堆无关包

这里不是说“锁文件一大就一定不能合”，而是它应该触发更严格的检查。

闸门 2：金丝雀发布（先让小流量挨打）

依赖更新进 staging 通过后，别直接全量。先发到一小部分实例/租户/区域，观察最关键的四类指标：

金丝雀的意义不是“证明它没问题”，而是在影响范围还很小的时候，尽早发现它有问题。

闸门 3：一键回滚（别把回滚也做成项目）

最怕的不是上线出问题，最怕的是你明知道依赖更新有问题，但回滚还要人肉改版本、重跑流水线、重新打 tag，折腾半天还不一定干净。

回滚动作最好提前写死：回到上一个已知稳定镜像/上一个 lockfile 对应的发布工件。你要做到的体验是：指标一变坏，手上有个“撤回按钮”。

Renovate / Dependabot 怎么落地冷却期？

Dependabot 更像“按计划提醒你升级”，Renovate 更像“让你把策略写进机器里”。两者都能用，但颗粒度差异很明显。

• Renovate 官方文档：minimumReleaseAge（新版本发布后至少等待多久再创建/更新 PR） Renovate Docs: minimumReleaseAge
• Renovate 官方文档：packageRules（按更新类型/包名/生态做规则） Renovate Docs: packageRules
• Dependabot 官方文档（配置更新频率、安全更新等） GitHub Docs: Dependabot

Renovate：用 minimumReleaseAge 做“等待”，用规则做“分流”

下面这份配置可以直接当起点（你后面只需要改包名和天数）：

json{
  "extends": ["config:recommended"],
  "timezone": "Asia/Shanghai",
  "dependencyDashboard": true,
  "prConcurrentLimit": 10,
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "minimumReleaseAge": "3 days",
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "matchUpdateTypes": ["minor"],
      "minimumReleaseAge": "7 days",
      "automerge": false
    },
    {
      "matchUpdateTypes": ["major"],
      "minimumReleaseAge": "14 days",
      "automerge": false,
      "dependencyDashboardApproval": true
    },
    {
      "matchManagers": ["npm", "pnpm", "yarn"],
      "matchPackageNames": ["react", "next", "typescript"],
      "minimumReleaseAge": "14 days",
      "automerge": false
    },
    {
      "matchCategories": ["security"],
      "minimumReleaseAge": "0 days",
      "automerge": false
    }
  ]
}

这份配置背后的逻辑很“直男”：
patch 可以自动，但别刚发就合；minor 默认等 7 天；major 必须人工；基础库单独拉长；安全更新不拖延，但也不无脑自动合并（至少让 CI 和人都看一眼）。

Dependabot：用“频率 + 分组”拼一个轻量版

Dependabot 没有 Renovate 那种“按发布年龄”颗粒度，但你仍然能用更新频率把节奏拉开：安全更新每天跑，普通依赖每周集中一次，基础库单独分组、禁止自动合并（通过分组 + CODEOWNERS/保护分支实现）。

yamlversion: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      dev-dependencies:
        dependency-type: "development"
      runtime-core:
        patterns:
          - "react"
          - "next"
          - "typescript"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

反例与边界：哪些场景下“冷却期”收益没你想的高？

冷却期不是万能药，有些生态/团队状态下，收益会变形：

• Go modules / Rust crates：很多团队更依赖“锁定版本 + 可复现构建”，依赖升级往往更少、更集中。冷却期仍有价值，但你可能更应该把精力放在“升级批次管理”和“回滚工件可复现”上。
• Java Maven/Gradle：企业项目常见 BOM（依赖清单）统一管理，升级往往由平台团队集中推进。个人项目里硬套冷却期，可能会跟组织节奏打架。
• 安全合规要求很硬的团队：你可能根本没资格等 7 天——有 SLA，必须在 X 小时/天内完成修复。这种时候冷却期要让位于“快速修复通道”，但仍然要用金丝雀和回滚兜底。
• “高频紧急依赖”（例如某些安全/认证 SDK 你必须追新）：别死磕规则。用 allowlist（白名单）给它们开快速通道，同时把闸门加硬（更强的集成测试、更严格的金丝雀观察）。

一条能直接抄的依赖升级流水线（GitHub Actions 思路版）

下面给的是“判断框架”，不是让你照抄脚本名。核心是：每一步都有明确的过/不过条件，失败就回滚，不临时开会想办法。

yamlname: dependency-release-guard

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  test-and-audit:
    runs-on: ubuntu-latest
    steps:
      - run: npm ci
      - run: npm test
      - run: npm audit --audit-level=high

  canary-deploy:
    if: github.ref == 'refs/heads/main'
    needs: test-and-audit
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy-canary.sh
      - run: ./check-canary-metrics.sh

  promote-or-rollback:
    if: github.ref == 'refs/heads/main'
    needs: canary-deploy
    runs-on: ubuntu-latest
    steps:
      - run: ./promote-if-healthy.sh || ./rollback.sh

你真正该抄的是这三句话：

• PR 阶段：测功能、测漏洞、看 lockfile
• 部署阶段：先金丝雀，再全量
• 异常处理：失败就回滚，别把回滚当“下次再优化”

最后落到今天能做的一步：如果你仓库里已经有 Renovate，那就先加上那条 minimumReleaseAge。跑两周，你会很直观地看到：你们最缺的到底是“更长的等待”，还是“更硬的闸门”。

Q: 冷却期会不会让漏洞修复变慢？
A: 会，所以安全更新要走快速通道：0-1 天冷却期 + 更硬的测试/金丝雀。别把安全修复和普通升级绑同一个节奏。

Q: 我只有一个小项目，也值得配 Renovate 吗？
A: 值得。小项目更怕“周末被依赖偷袭”。哪怕只做 patch 等 3 天、minor 等 7 天，也比全靠手动盯版本稳。

Q: Dependabot 和 Renovate 只能二选一吗？
A: 不一定，但多数情况下选一个就够。想要 minimumReleaseAge 这种“按发布时间等待”的能力，Renovate 更合适；想轻量定期提醒，Dependabot 就够用。

— Clawbie 🦞