可攜 Chrome 更新器 chrome_updater，直接抓官方離線安裝包

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

安裝版 Chrome 的使用者一輩子不用想「更新」這兩個字：背景的 Google 更新器會自己把事情辦好。把 Chrome 拆成資料夾、放進隨身碟帶著走的人，處境剛好相反，每次改版都要手動抓離線安裝包、解壓縮、換掉整組程式檔，還得自己記得查有沒有新版本。同一套瀏覽器，兩種使用者待遇差這麼多，差別只在於有沒有人替它跑腿。

chrome_updater 補的就是這個缺口。它是一套 Go 語言寫成的開源 Windows 小工具（AGPL-3.0 授權，2024 年 1 月起步，2026 年 9 月剛推出 v2.7），放在可攜版 Chrome 的資料夾裡執行，就能檢查四種版本軌道的最新版號、下載官方安裝套件、驗完雜湊值後就地換掉舊版。整件事最值得攤開來看的，是它取得版本資訊的方式。

它對 Google 官方更新服務講安裝版的語言

打開 chrome_updater 的原始碼，版本檢查沒有任何中間人：程式直接對 tools.google.com/service/update2 送出請求，這正是 Google 官方更新器定期替安裝版 Chrome 查版本用的同一個服務、同一套 Omaha 更新協議。原始碼裡內建了十二份 Windows 請求模板，對應 stable、beta、dev、canary 四種版本軌道乘上 x64、x86、arm64 三種架構，請求裡帶的是 Chrome 官方發行的應用程式識別碼，User-Agent 字串也仿照 Google Update 官方客戶端的格式。換句話說，它把自己裝成安裝版 Chrome 的官方更新器去問版本，Google 的伺服器據此把正式的版本清單交出來。

把程式裡那份 stable x64 的請求模板原樣送一次，可以看見官方應答的完整內容：目前穩定版是 154.0.8037.98，套件名稱 154.0.8037.98_chrome_installer_uncompressed.exe，大小 519,395,752 bytes（約 495 MiB），附帶 SHA1 雜湊值，以及六個下載基地址，分屬 edgedl.me.gvt1.com、dl.google.com、www.google.com 三個 Google 官方網域，應答裡甚至帶著「Stable Installs & Version Pins」這種官方版本分群標籤，看得出來這份清單確實出自 Google 更新系統的正式管線。介面上的「下載通道」三選項，對應的就是應答裡這三個主機，斷線時可以換一個再抓。

Pin

這件事對信任判斷的意義很直接：版本號、安裝套件、雜湊值全部出自 Google 官方伺服器的應答，chrome_updater 沒有轉手包、沒有自架鏡像、也沒有在中間動過手腳。第三方更新器最讓人擔心的「安裝檔來路」問題，在這裡的答案是清一色的 Google 官方 CDN。

順帶一提那個將近 500 MiB 的體積：官方應答給穩定版 x64 的是「未壓縮版安裝器」，內容沒有再包一層壓縮，所以抓下來就能直接解，代價就是體積比傳統雙層壓縮的離線安裝包大得多。程式兩種格式都會處理，抓到傳統安裝器就多解一層，抓到未壓縮版就省一步，使用者不用管差異。

小地方也有講究。這個套件的官方應答只附 SHA1，沒給 SHA256 的值，所以主畫面上 SHA256 那一欄會是空的，不是程式壞掉；完整性比對用 SHA1 就夠了，因為傳輸全程走 https，雜湊比對的目的是防下載過程的損壞與竄改，不是密碼學簽章。三個下載通道也值得認識一下：edgedl.me.gvt1.com 是 Google 自家的檔案派送網域，dl.google.com 是官方下載站，www.google.com 則是備援路徑，三個都姓 Google，差別只在頻寬調度與連線品質，拿不準就讓程式用預設值。

從下載到換版，中間發生什麼

確認安裝後的流程，原始碼也寫得明白。下載器用十六條執行緒分塊抓檔，區塊大小在 256 KB 到 4 MB 之間自動調整，中途斷線會留下 .gdl 進度檔供下次續傳，單一區塊最多重試三次。檔案抓完後，程式先計算 SHA1，與官方應答給的雜湊值逐字比對，相符才繼續往下走，不相符就直接標記失敗、不動你現有的 Chrome。

驗完雜湊才輪到解壓。程式內嵌了 7-Zip 的命令列工具三份，對應三種 CPU 架構，這也是發行包將近 12 MB 的主要體積來源；先用它解出 chrome.7z，再以純 Go 的解壓函式庫攤開，把 Chrome-bin 目錄的內容上移一層，就地完成換版。整段流程不需要你另外安裝解壓縮軟體，也不會動到 Windows 登錄檔，可攜的歸可攜。過程中有兩個防呆：chrome.exe 正在執行時會拒絕動手，避免蓋掉使用中的檔案；更新完成後預設刪掉安裝檔與舊版資料夾，想留著舊版當退路的人，要先到設定頁打開兩個保留選項。

第一次使用則是另一條路：指定空資料夾後，程式會建立 App、Cache、Data 三個子目錄的標準可攜配置再裝入 Chrome，順手也能替它建一個桌面捷徑。設定頁還能開每小時一次的自動檢查，開啟之後關閉視窗不是退出，而是縮進系統匣繼續待命，背景發現新版就自己下載換好；就算不開自動檢查，程式啟動時也會先查一次版本。工具本身也有自我更新，檢查到新版會自己下載、把舊的執行檔改名讓位、重新啟動，不必手動換程式。

還有一件隱私面上的事值得講清楚。實際會發出請求的網路觸點就四類：Google 更新服務、三個 Google 官方下載網域、GitHub 上的版本清單鏡像、GitHub releases 的檔案下載。沒有分析服務、沒有使用統計、沒有把任何使用紀錄送出去的程式碼；設定檔就存在本機的 AppData 或 Chrome.exe 旁邊，偏好設定、代理位址、版本軌道選擇全部留在自己機器上。對一套需要網路才能做事的工具，它的網路足跡稱得上乾淨。

三個常見疑問

這樣裝出來的 Chrome 是正版嗎？ 是。安裝套件從 Google 官方 CDN 的三個網域下載，套件本身就是 Google 發行的官方檔案，下載後還用官方應答裡的 SHA1 驗證完整性。它做的事情接近官方離線安裝頁的手動流程，只是把查版本、抓檔、解壓、換檔四件事接上自動化。

只想要穩定版，還是有別的選擇？ stable、beta、dev、canary 四軌都在主畫面選得到，想嚐鮮的人也可以拿它來裝 beta 或 canary。不過發行包只有 Windows 的三種架構，原始碼裡雖然留著 macOS 的請求模板，官方從未發布對應的執行檔，macOS 使用者目前不在服務範圍。介面語言有英文與簡體中文兩種（外加跟隨系統），沒有繁體中文。

需要代理的網路環境能用嗎？ 可以。版本檢查直連失敗時，程式會自動改走 Windows 系統代理；設定頁也可以自己填代理位址，支援 HTTP(S) 與 SOCKS5 兩種連線方式，或是指定 GitHub 代理前綴，下載 Chrome 時是否也走代理另有獨立開關。

更新會動到我書籤跟設定嗎？ 不會。換版流程動的只有程式檔本身：解壓出的新版本檔案蓋到上一層目錄，舊的版號資料夾依設定清除，使用者資料所在的 Data 目錄與快取所在的 Cache 目錄都不在更動範圍。自動更新也是同一套流程，差別只在排程每小時檢查一次，chrome.exe 正在執行時就跳過那一輪，等下一輪再說。

兩個現況邊界

邊界之一在 Chrome++ 分頁。這套工具有另一個身分：替可攜版 Chrome 安裝、更新名為 Chrome++ 的強化模組（一種放在 chrome.exe 旁邊的 version.dll，用來做資料目錄重導向、分頁手勢之類的強化）。v2.7 的介面提供兩個分支：Chrome++ Next 與 ChromeGreen，程式啟動時還會讀 version.dll 的檔案描述來自動判斷你裝過哪一個。問題在於 Chrome++ Next 的上游，也就是 Bush2021 的 GitHub 帳號與整個 chrome_plus 專案，現在都已經不存在，GitHub 查這個帳號得到的狀態是 404。程式抓版本清單用的鏡像位址也一樣：實際抓取那份清單，得到的內容就是 404 訊息本體。換句話說，介面上這個分支還在，按檢查卻只會等到更新失敗的提示，實際能用的強化路線只剩作者自己的 ChromeGreen。

Pin

這條支線的故事其實有點滄桑。Chrome++ 的維護棒子原本在 Bush2021 手上（chrome_updater 的鳴謝名單也感謝了早期作者 shuax），如今連人帶庫一起消失，接棒的竟是 chrome_updater 作者自己跳下來寫的 ChromeGreen，新專案的分頁強化程式碼也註明是從 chrome_plus 移植。強化模組這條路的存續，端看有沒有人願意一直顧著它。

另一個邊界是它的維運規模。整個專案由開發者 Libs 一個人維護，308 個星、一個未決 issue，發版節奏倒是一直活著：2025 年 4 月到 2026 年 9 月之間出了六個版本，2026 年 9 月下旬還有人在通報問題、作者也真的在處理（例如 64 位元系統抓到 32 位元套件的案例，幾天內就結案）。另一面是單人專案的壽命沒有保證，真遇到問題，求助管道只有 GitHub issues 一條。另外官方 repo 附的介面截圖是 0.0.1 開發期的畫面，欄位佈局可以參考，版本數字別當成現況。

它的下一代已經出現，作者是自己人

v2.7 的發布說明裡有一段少見的坦白。作者寫道，新的 ChromeGreen 支援自我更新，如果你使用這個版本，可以捨棄 chrome_updater，這代表未來的方向，但更新器會繼續支援並提供 Chrome++ Next 的更新。翻譯成白話：強化與可攜這條路的終點形態，是把更新器做進強化模組本身，chrome_updater 則繼續把更新器本業顧好。後半句承諾讀來有點微妙：作者答應持續照顧的 Chrome++ Next，上游已經消失，這個分支要怎麼走下去，只能看後續發展。開發者願意在自己的發布說明裡告訴你「有別的選擇」，這種坦白在工具圈並不常見，也讓這段世代交替少了點猜測、多了點可信。

ChromeGreen 是作者 2026 年 7 月才開的新專案（GPL-3.0，C++ 撰寫），用途是讓 Chrome 完整可攜：資料、快取、機器識別資訊全部重導向，隨身碟插上就用；更新器與設定頁都做在模組裡，改設定不用碰設定檔。用 chrome_updater 安裝它的動作也很單純，抓 zip 解出一個 version.dll 放到 chrome.exe 旁邊就完成。它到 2026 年 9 月下旬仍在穩定發版。兩者怎麼選，作者已經點出方向：只想要可攜版 Chrome 自動更新的人，chrome_updater 夠用而且單純；想要資料跟著走、分頁強化、老闆鍵這整套的，直接上 ChromeGreen，代價是接受 version.dll 注入這種運作方式，以及企業環境或防毒軟體可能帶來的摩擦。

誰該裝它，誰不用麻煩

用一般方式安裝 Chrome、也只有一台電腦在用的人，不需要這套工具，官方更新器已經把你照顧得很好。它真正的使用者畫像是：把 Chrome 放在隨身碟或資料夾裡帶著走、重灌電腦像吃飯、或者需要同時維護好幾份不同版本軌道的人。公司電腦沒有安裝權限、只能用可攜軟體的上班族，以及需要驗證舊版網頁相容性的開發者，都是典型場景。對這群人來說，手動抓離線包的流程每個月都要走一次，交給工具顯然省事。

配套的生態也值得一提：可攜環境裡最常遺失的擴充套件清單，可以交給 Chrome 擴充套件同步器 處理；想讓瀏覽器本體更精簡的人，搭配 Chrome 與 Edge 的瘦身指南 一起看；MaoXian 網頁剪藏 這類把資料存在自己磁碟裡的擴充功能，跟可攜瀏覽器的思路剛好同一族。工具鏈自己挑，判斷只有一條：確認你的 Chrome 需要「帶著走」，再考慮誰來替它更新。