Chrome 发布周期从四周变成两周，前端团队的发布节奏正在被这件事彻底重新定义

Chrome 的发布节奏变了。

从 2021 年到上周，Chrome 每四周发布一个稳定版。9 月 8 日之后，这个数字变成了两周——Chrome 153 是第一个按新日历跑稳定发布的版本，桌面、Android、iOS 全平台同步切换。

这件事对你的影响比你想象的更具体。

压缩的不是版本号，是你的准备时间。

按照旧节奏，一个功能在 Beta 频道有大约四周的测试窗口。按新节奏，这个窗口缩短到三周。更短的测试周期意味着：你的 QA 团队在 Beta 阶段发现问题的压力变大了，发现晚了就没时间等修复进稳定版。

Chrome 官方博客的公告里明确说了这个目的：更多但更小的发布，每次变更范围更小，回归更容易定位。这个逻辑是成立的——但它成立的前提是你的团队跟上了这个节奏。

三个地方你得改。

第一，监控策略得升级。Chrome 现在每年会发布约 26 个稳定版（之前是 13 个），每个版本都可能包含新的平台行为或已知问题的变化。你需要能更快识别「这个问题是新 Chrome 版本引起的」而不是先去查自己的代码。

第二，CI/CD pipeline 的浏览器版本策略要重新设计。如果你的自动化测试还在跑固定版本的 Chrome，现在得考虑用更灵活的机制——比如用非最新版跑回归测试，确保新版本发布当天你的测试套件不会突然全红。

第三，Extension 维护者的压力最大。Chrome 扩展 API 每年会因为这个变化多变更十几次。主动维护的扩展会适应得很快；半途而废的会开始积累兼容债务。

企业用户有一个例外。

Chrome 的 Extended Stable 频道保持八周周期不变，企业管理员如果配置了这个选项，用户仍然按照季度节奏收到更新。如果你服务的企业客户还在跑 Extended Stable，你的支持矩阵必须覆盖两个节奏——新节奏和季度节奏。

怎么应对？

建议现在就去检查你的测试基础设施：是否锁死 Chrome 版本？是否有能力在多个版本上并行跑测试？如果答案都是否，先把这个补上，比追新功能优先级更高。

Chrome 加速发布这件事，对大多数用户来说是安全补丁到得更快了。对前端工程化团队来说，是手里的工具链得跟着升级。