Chrome 的大版本更新，从每 4 周一次改为每 2 周一次。切换后的第一个版本是 153，桌面端、Android 和 iOS 全部适用。这次调整的目的不只是让新功能来得更快，更在于压缩修复代码公开之后、真正送到用户手中之前的那段空白。
从 153 版起，4 周的间隔缩短一半
Chrome 保持 4 周一个大版本的节奏是从 2021 年开始的。2023 年又加入了每周一次的安全更新，以及面向部分用户提前推送的早期稳定版，更新的颗粒逐步变细。这次是在同一条路线上，把大版本本身的间隔直接减半。
覆盖范围包括桌面端、Android 和 iOS。开发用的 Dev 频道与 Canary 频道维持不变。测试版会在稳定版发布的 3 周前推出，运营网站或 Web 应用的一方仍然可以提前验证行为是否受影响。
由于每次更新携带的改动变少，单个版本的体量也随之变小。这带来一个附加好处：出现异常时，需要排查的范围更窄。
时间表整体提前了 2 到 4 周
切换前后，各版本的日期集体向前移动。153 版的稳定版原定 9 月 22 日发布，实际上 9 月 8 日就已经推出。切分支的日期从 8 月 24 日提前到 8 月 17 日，测试版晋级也从 8 月 26 日提前到 8 月 19 日。
接下来的 154 版变动更大。按旧节奏本应在 10 月 20 日发布的稳定版，改为 9 月 22 日，大约提前了 1 个月。此后版本号将以每 2 周一次的速度推进。过去凭版本号判断更新时机的做法，需要重新建立感觉。
背后是 AI 挖出来的漏洞数量
缩短间隔的判断，源于需要修复的缺陷突然变多。Chrome 的安全团队多年来一直用大语言模型寻找漏洞，而 2026 年初搭建的、基于 Gemini 的智能体框架让搜索效率上了一个台阶。当时发现的其中一个问题是沙箱逃逸，被攻破的渲染进程可以骗过浏览器去读取本地文件，而这个缺陷已经在代码库里存在了 13 年以上。
具体数字体现在 149 和 150 两个版本上。仅这两个里程碑就修复了 1,072 个安全缺陷，超过此前 23 个里程碑的总和。来自外部研究者的报告同样在增加，到 2026 年 3 月，收到的数量已经超过 2025 年全年。
发现的量一旦上来，处理端也只能自动化。过去每份报告需要 5 分钟到 30 分钟以上的分诊工作，被改为规则判断与机器判断相结合的流程，涵盖重复与垃圾信息的过滤、复现确认、严重程度标注，以及分配给具体负责人。修复方案本身，也由生成侧的智能体与担任评审的智能体反复往返，以接近代码评审的方式打磨。
修复一旦公开，与攻击方的赛跑就开始了
修复进入开源代码的那一刻，内容对所有人可见。攻击者可以从差异反推出弱点，赶在更新普及之前动手，这就是所谓的 N-day 攻击。用来描述修复落地到抵达稳定版之间延迟的补丁空窗（patch gap），指的正是这个窗口的宽度。
每 2 周一次的大版本更新，是收窄这个窗口的一步。每周一次的安全更新照常进行，同时还在试验把频率提高到每周 2 次。
再往前一层，尚未解决的是用户重启浏览器所需的时间。更新会静默下载并等待，但真正生效要等到重启之后。谁都有不想中断手头工作的理由，所以这一段很难压缩。相关的应对包括动态打补丁的研究，即依次替换后台子进程从而免去完整重启；以及在 macOS 上检测到一个窗口都没有打开的状态时自动重启的行为。
面向企业的 Extended Stable 仍保持 8 周
更新变快也会给一些场景带来困扰，比如需要逐项验证与内部系统兼容性后再分发的企业，以及把 Chromium 嵌入自家产品的开发方。面向这类用户的 Extended Stable，仍然维持原有的 8 周间隔。Chromebook 同样保持先完成专门验证再推送的方针。
管理员一侧也有可用的手段。要避免更新长期挂起不生效，可以启用逐步升级提示强度、最终强制重启的策略。以验证为优先的环境适合选择 Extended Stable，而设备实际运行在哪个版本，可以通过管理用的仪表板掌握。
总结
Chrome 从 9 月 8 日的 153 版起，把大版本更新的间隔缩短为 2 周。新功能来得更快是显而易见的变化，但真正的重点在于压缩安全修复公开之后送达用户之前的空白。既然 AI 让被发现的漏洞数量上了一个数量级，只提高修复速度而不提高分发速度就无法匹配。用户这一侧能做的最短一步很简单：发现有更新在等待时，把浏览器重启一次。
