Chrome 的大版本更新，從每 4 週一次改為每 2 週一次。切換後的第一個版本是 153，桌機、Android 與 iOS 全部適用。這次調整的目的不只是讓新功能更早抵達，更在於壓縮修補程式公開之後、真正送到使用者手上之前的那段空白。
自 153 版起，4 週的間隔縮短一半
Chrome 維持 4 週一個大版本的節奏是從 2021 年開始的。2023 年再加入每週一次的安全性更新，以及先行推送給部分使用者的早期穩定版，更新的顆粒逐步變細。這次是在同一條路線上，把大版本本身的間隔直接減半。
涵蓋範圍包括桌機、Android 與 iOS。開發用的 Dev 頻道與 Canary 頻道維持不變。測試版會在穩定版推出的 3 週前釋出，經營網站或網頁應用程式的一方仍然可以提前確認行為是否受到影響。
由於每次更新帶進來的變動變少，單一版本的份量也隨之縮小。這帶來一個附帶好處：出狀況時，需要排查的範圍更窄。
時程表整體提前了 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 讓被發現的漏洞數量上了一個數量級，只提高修補速度而不提高派送速度就無法相稱。使用者這一側能做的最短一步很單純：發現有更新在等待時，把瀏覽器重新啟動一次。
