Worker 與分頁共用同一份記憶體配額

常見誤解：「把重活丟到 Worker 就能繞開記憶體限制」。繞不開——Worker 跟分頁在同一個 renderer process，向作業系統要的是同一份預算。

OS process：renderer（一個分頁進程）
├── 主執行緒
│   └── V8 isolate ①：React / DOM / store
└── Worker 執行緒
    ├── V8 isolate ②：worker 的 JS
    └── WASM linear memory：那幾百 MB

「另外開一塊」這個直覺對了一半：Worker 確實有自己的 V8 isolate——獨立的 heap、獨立的 GC、獨立的 hidden class 表，兩個 isolate 之間不能直接共享物件參照（這正是 postMessage 只能傳可序列化資料或 transferable 的原因）。所以 Worker 的 GC 停頓不會卡住畫面。

但 isolate 不是 process。 可驗證的三個推論：

• 分頁被 OOM 砍掉時 Worker 一起死（Chrome 的 Aw Snap 是整個 renderer 掛掉）
• 工作管理員（Shift+Esc）的數字以 process 為單位統計，包含 Worker
• 開 Worker 不會多拿到記憶體——只繞開執行緒阻塞，沒繞開記憶體上限

真正在不同 process 的是 Service Worker（獨立於分頁存活）與 cross-origin iframe（site isolation）。

各環境上限：桌機 Chrome renderer 約 2–4GB／單一 ArrayBuffer 約 2GB／iOS Safari 每 process 只有數百 MB，超過直接被系統砍掉、連 error event 都沒有。

相關：WASM linear memory 是 GC 管不到的記憶體、記憶體峰值倍率：OOM 發生在轉換的瞬間