BrowserPod：瀏覽器分頁內的 Linux 相容核心，WebAssembly 原生設計深潛
Leaning Technologies · 2026-05-18
BrowserPod 是 Leaning Technologies 開發的瀏覽器原生沙盒，在單一瀏覽器分頁內實作一個與 Linux 相容的作業系統核心。不同於過去把 Linux 核心編譯成 WebAssembly 的嘗試，BrowserPod 從零設計一個 WebAssembly 原生核心，透過標準化的 Linux 系統呼叫介面讓現有程式不需修改即可執行。支援的生態系涵蓋完整 Python 環境、Git 工作流程、以及含 npm 安裝的 Node.js 全端應用程式。
核心改動
每個程式以一個 WebAssembly 二進位檔執行，並由 Web Worker 提供並行能力——多執行緒程序共用記憶體跨 Worker 共享，單執行緒程式則獲得隔離記憶體。所有應用程式透過 Linux 相容系統呼叫與中央 BrowserPod WebAssembly 核心溝通。程式以 Cheerp 這個 C/C++ 編譯器編譯至 wasm32-browserpod-linux 目標架構。
檔案系統採用 Ext2 實作，以區塊為基礎串流載入磁碟映像。映像透過 HTTP byte-range 請求或 WebSocket 依需求漸進式下載，並以 OPFS 或 IndexedDB 在本機快取。這讓冷啟動時只需先取得必要區塊，其餘部分延遲載入。
網路出站流量透過 Cloudflare Workers 路由；入站流量則使用「Portals」——自動生成的域名將 HTTP 流量導入沙盒，並有白名單機制防止濫用。這種設計讓在沙盒內運行的 dev server 可以對外暴露，但不需要任何 WebRTC 或 NAT 穿透。
架構與 Linux 核心的對應
BrowserPod 核心架構與傳統 OS 核心高度對稱：
- 硬體抽象：透過標準化 API（檔案、Socket、裝置）遮蔽底層 Web 平台差異
- 程序隔離：WebAssembly 線性記憶體模型提供天然的程序邊界
- 資源協調：核心確保對共享狀態（如虛擬檔案系統）的有序存取
- 並行執行：Web Worker 對應到 OS 執行緒，由宿主 OS 排程
影響範圍
BrowserPod 讓瀏覽器成為可執行完整 Linux 應用程式生態系的容器環境，無需伺服器端計算資源。示範場景包括：Python 程式設計環境、含 GitHub 整合的 Git 工作流、以及多個並行程序共同操作同一虛擬檔案系統的全端 Node.js 應用程式。與 Emscripten 把單一應用程式移植到 WebAssembly 的方式不同，BrowserPod 的核心介面設計讓整個程式生態系可以在不修改源碼的情況下運行。
GitHub Issues 導覽效能現代化：IndexedDB 快取命中 96%、P10 從 600ms 降至 70ms
GitHub Engineering · 2026-05-14
GitHub 工程團隊發表案例文章，說明如何將 Issues 頁面的 P10 導覽延遲從 600ms 壓縮至 70ms，並讓 30% 的導覽達到低於 200ms 的「即時」門檻。核心方案是三層漸進式快取架構，結合 IndexedDB 持久化儲存、主動式預熱策略，以及 Service Worker 攔截機制。
核心改動
第一層：IndexedDB stale-while-revalidate。瀏覽器在本機持久化快取 Issue 資料；使用者導覽時先立即從快取渲染，同時在背景向伺服器重新驗證。初始部署讓 22% 的 React 導覽達到即時，快取命中率約 33%。
第二層：Preheating（預熱）策略取代傳統激進式 prefetch。系統主動走訪高意圖的 Issue 引用並預先填充快取，而非盲目預抓所有連結。結合頻率限制與電路斷路器（circuit breaker）避免頻寬濫用後，快取命中率從 33% 擴展至約 96%。
第三層：Service Worker 攔截。Service Worker 攔截導覽請求並檢查本機快取可用性；快取命中時向伺服器發出信號跳過重型計算，同時縮小初始 payload。另外加入一層記憶體內快取（in-memory cache）處理熱點 Issue，繞過 IndexedDB 的非同步成本。
實際效果
| 百分位 | 改善前 | 改善後 |
|---|---|---|
| P10 | 600ms | 70ms |
| P50 | 1,200ms | 700ms |
| P75 | 1,800ms | 1,400ms |
整體約 30% 的導覽達到即時（<200ms），其中 React 特定導覽約 70% 達到此門檻。設計上刻意選擇「預熱」而非「預抓」，避免大量無效預取造成頻寬浪費——只有使用者實際高機率會點的 Issue 才會被預先載入。