Skip to main content

Chrome 的四通道发布机制

· 5 min read

Chrome 用 4 个发布通道（Canary / Dev / Beta / Stable）同步推进，同一份代码按顺序流过所有通道后才进入 Stable。

  1. Canary：每天构建，测试最少，可能导致崩溃。
  2. Dev：每周 1-2 次构建，可能和 Canary 在同一个 MAJOR。
  3. Beta：每周小更新 + 每 4 周大更新，比 Stable 早一个月以上拿到新功能。
  4. Stable：每 2-3 周小更新 + 每 4 周大更新，分阶段从 1-5% 灰度到 100%。

核心反直觉："渠道 ≠ 版本"。MAJOR 号是里程碑（M101、M102、M103…），不是"我现在用的是第几代 Chrome"。同一时刻 Stable、Beta、Dev/Canary 经常对应 3 个连续的 MAJOR —— 但 Dev 和 Canary 可以共享同一个 MAJOR。

前情提要：Chrome 150 打印预览 bug​

前几天 Chrome 自动升级到 150.0.7871.187，Cmd+P 打印预览里只剩项目符号（•）和箭头（→），正文全部消失。Safari 同一页面同一字体栈打印正常，问题只出在 Chrome 150 + macOS Sequoia 15.7.7。

排查到一半发现 Chrome 有 4 个并行发布通道，但 我对它们的理解几乎全错 —— 错得值得专门写一篇博客。

四个通道各做什么​

通道节奏测试强度适用人群
Canary每天最低，可能崩溃需要第一时间测新功能的开发者
Dev每周 1-2 次比 Canary 多提前看到 Chrome 正在开发的功能
Beta每周小更新 + 每 4 周大更新充分测试想"比稳定版提前一个月以上"用新功能
Stable每 2-3 周小更新 + 每 4 周大更新最严格普通用户默认渠道
tip

Stable 的 "每 X 周" 是两层叠加：

  • 每 2-3 周 一次安全 / 补丁小更新
  • 每 4 周 一次 MAJOR 号切换 + 大功能合入

反直觉的核心：渠道 ≠ 版本​

Chrome 版本号结构：

MAJOR  . MINOR  . BUILD  .  PATCH
 150   .   0    . 7871   .   187
  ↑        ↑        ↑         ↑
  │        │        │         └─ 补丁号（不规律）
  │        │        └─────────── 编译号（每构建 +1）
  │        └──────────────────── 副版本（基本永远是 0）
  └───────────────────────────── 里程碑（每 4 周 +1）

MAJOR 是里程碑，多个通道可以共享同一个：

Stable = 150
Beta   = 151
Dev    = 152  ┐
Canary = 152  ┘ 同一个 MAJOR，仅 BUILD 号差几十

Dev 和 Canary 都在同一份 main 分支上构建，区别是构建频率（Dev 每周 1-2 次，Canary 每天）。它们之间的版本号差通常只有几十个 BUILD，对应几天到一周的提交量。

只有当 main 推进到 下一个里程碑 时，新 MAJOR 才会从 Canary 开始冒出来，然后 Dev 跟上，再走 Beta → Stable。

MAJOR 号的生命周期​

一个 MAJOR（M100、M101、M102…）的实际旅程：

main 分支持续开发
   │
   ├─ [里程碑 M(N+1) 从 main cut] ──────────────► 新 Beta 分支
   │                                           ↓
   │                                    [4 周稳定化期]
   │                                           ↓
   │                                    升 Stable（M(N+1)）
   │
   ├─ [里程碑 M(N+2) 从 main cut] ──────────────► 新 Beta 分支
   │                                           ↓
   │                                    [4 周稳定化期]
   │                                           ↓
   │                                    升 Stable（M(N+2)）
   ...

同一个 MAJOR 在 main 上停留的时间 ≈ 4 周。这就是为什么每 4 周会有一个新 Stable。

四个通道在"同一时刻"的关系​

以当前（2026 年 7 月底）为例：

通道当前 MAJOR状态代码来源
Stable150已发布4 周前的 main（已冻结）
Beta151稳定化中7/22 cut，8/19 升 Stable
Dev152持续前进main，每周一两次切
Canary152持续前进main，每天切

注意 Dev 和 Canary 都是 M152 —— 只是 Canary 更新更频繁，能最快反映 main 的变化。

打印预览 bug 在 Canary 152 修复、Beta 151 没修，正好印证这个模型：

  • 修复落在 main 上（被 Canary 152 立即捕获）
  • 但 151 里程碑已经在 7/22 cut 出来进入冻结期，修复无法自动 backport
  • 必须等 151 升 Stable 之后、152 升 Beta → Stable，修复才能到普通用户手里

实际意义：什么时候用哪个通道​

场景推荐通道下载
日常开发、依赖稳定Stablegoogle.com/chrome/
提前 4 周体验新特性 + 提前发现 bugBetagoogle.com/chrome/beta/
提前看 Chrome 正在开发的功能Devgoogle.com/chrome/dev/
验证某条主线上修没修关键 bugCanarygoogle.com/chrome/canary/

真有用的场景：如果你遇到一个 Chrome bug，不确定是 Chrome 引擎回归还是网站代码问题，装个 Canary 30 秒验证：

  • Canary 修了 → Chrome 引擎 bug，等 Stable 跟上（看修复落在哪个 MAJOR，决定要等几周）
  • Canary 没修 → 大概率是网站代码问题，别去怪 Chrome

Chrome 把 4 个通道都做成独立安装、能并存，真不是给开发者玩票用的 —— 是给自己和生态做 release train 验证的：每个 MAJOR 在 main 上停留 4 周，刚好够让 Canary 早期用户、Dev 深度用户、Beta 灰度用户、Stable 全体用户依次踩一遍。

References​

  1. Chrome 发布通道（Chrome Release Channels） —— Chrome 官方文档
  2. Chrome Release Calendar —— 各通道当前版本和发布计划