兩層沙盒疊在一起會發生什麼：谷歌測試Flatpak版Chrome，動的是Linux發行通路的舊格局

2026年8月25日，Chromium開發者Tom Anderson向Chromium原始碼庫提交了一批新檔案，位置在chrome/installer/linux/flatpak/目錄下，內容包含Flatpak打包腳本、元資料模板、AppStream資訊與啟動入口。三天後，科技媒體NeoWin於8月27日發文披露此事，IT之家於8月28日跟進報導。一件尚未有時間表、未有穩定版承諾的工程實驗，之所以值得放進市場觀察的框架裡讀，原因在於它碰觸了Linux桌面軟體分發長期未解的一條成本線：官方打包與社羣打包之間的維運責任歸屬。

先把技術事實釐清。谷歌目前為Linux版Chrome提供RPM與DEB兩種安裝包，對應Fedora、openSUSE與Debian、Ubuntu兩大陣營的傳統系統級套件格式。Flatpak則是另一種路線：應用被裝進沙盒，對宿主系統檔案、裝置與資源的存取都受限制，優勢是跨發行版，一次打包可在多數Linux桌面環境安裝執行。這次提交的程式碼新增了名為enable_flatpak的GN建構參數，預設值為false，也就是一般Chrome與Chromium的建構流程不會自動產出Flatpak包，這明確定位為實驗性質。程式碼同時為兩個瀏覽器預留了應用標識：Chromium對應org.chromium.Chromium，Google Chrome對應com.google.Chrome。

雙重沙盒為什麼是障礙

Chromium系瀏覽器本身就有一套多進程沙盒，用來限制網頁分頁與渲染進程的系統權限，這是瀏覽器安全模型的核心層。Flatpak再在外面套一層沙盒，兩套隔離機制嵌套，系統呼叫的行為就會出現預期外的攔截與失敗，功能異常難以排查。這是Chromium系瀏覽器長期缺乏官方Flatpak版本的主要技術原因。

社羣的既有解法是Zypak相容層，透過攔截部分系統呼叫，讓Chromium能在Flatpak環境裡正常運作。Flathub上的社羣維護版本走的正是這條路。但相容層本身就是一種成本：它由社羣維護，追蹤上遊Chromium的更新節奏存在時間差，出問題時責任鏈條也模糊，使用者向谷歌回報的bug，可能根源在社羣打包層。

谷歌這次實驗採取的路徑不同，聚焦測試受限沙盒配置，並擴大既有的XDG Portal支援。XDG Portal是Flatpak生態中應用與宿主系統溝通的標準介面，檔案選擇、螢幕共享、通知等能力都經由它申請。換言之，谷歌嘗試的方案方向，是讓Chromium的內部沙盒與Flatpak的外部沙盒在設計層面協調，而非靠外部相容層硬接。

這本帳的兩端：通路成本與維運責任

從分發通路結構看，Linux桌面對Chrome的意義與Windows、macOS不同。Linux桌面在全球作業系統市佔中長期處於低個位數（StatCounter等機構的長期追蹤大致落在3%至4%區間，且包含Chromebook貢獻的Chrome OS），商業權重有限。但Linux桌面用戶中開發者與技術意見領袖密度高，這個族羣對瀏覽器標準、Web API採用的輿論影響力，遠超其人數佔比。谷歌維持Linux版Chrome的動機，更多在於生態話語權而非直接營收。

RPM與DEB雙軌並行，意味着谷歌每個版本都要維護兩套打包流程與依賴處理。Flatpak若跑通，理論上一套包覆蓋多數發行版，打包維運成本集中化。這是格式替代曲線上常見的算式：前期投入相容工程成本，換後期維運結構的簡化。不過這筆帳目前只在假設階段，谷歌未給出上線時間、穩定版範圍或功能一致性承諾，實驗代碼與產品決策之間的距離，在Chromium的歷史上並不短。

對照歷史，Mozilla的Firefox早在數年前就提供官方Flatpak，微軟的Edge維持RPM/DEB路線，Brave等Chromium系瀏覽器則多依賴社羣或第三方打包。谷歌若成為第二家官方支援Flatpak的主流瀏覽器廠商，對Flatpak生態的訊號效應大於對Chrome市佔的實際影響。

誰受惠，誰承壓

受惠端先是Flathub與Flatpak生態本身。谷歌官方入場帶來的是格式正當性的背書，開發者會把「連Chrome都做了Flatpak」當成打包決策的參考點。其次是終端用戶中的滾動更新發行版使用者，官方包意味着更新延遲縮短、沙盒權限配置經過谷歌自己測試。

承壓端則是現有的社羣維護者。一旦官方Flatpak版上線，Flathub上的社羣版使用者會逐步遷移，維護者的工作量與影響力同步縮減。這是開源生態裡反覆出現的替換模式：社羣先行驗證需求，官方收割通路，中間的過渡期長短取決於官方版本的功能完整度，尤其 DRM、密碼管理員整合、硬體加速這類對系統資源存取敏感的功能，恰好是雙重沙盒問題最容易爆雷的位置。

再往下遊看，發行版官方倉庫的維護者也受影響。Flatpak繞過了發行版的套件審查與凍結週期，應用更新直接來自開發者。對追求穩定的企業發行版而言，這是治理介面的轉移，不是單純的便利升級。

收束判斷

以現有資訊定性，這是一次建構系統層面的準備動作，enable_flatpak預設關閉的設計說明谷歌自己也不確定何時放量。值得持續追蹤的觀察點有兩個：一是該GN參數何時轉為預設開啟或進入官方建構流程，那纔是產品決策落地的訊號；二是受限沙盒配置的測試範圍是否覆蓋DRM播放與GPU加速這類高摩擦功能。在此之前，將其解讀為「Chrome即將全面Flatpak化」超出了證據所能支撐的範圍。這則消息的價值，在於它讓Linux桌面軟體分發長期的責任歸屬問題，重新回到了工程討論的桌面上。