一次轉換 500 張照片瀏覽器為什麼不會當機？瀏覽器端 JSZip 串流封裝技術解密

許多人以為一張 5MB 的 JPG 照片在記憶體裡只佔 5MB，這是極大的誤解！ * **磁碟儲存**：JPG 檔案在硬碟中經過了高度壓縮。 * **記憶體解碼**：當瀏覽器準備轉換這張圖片時，必須將其解壓縮為未壓縮的 RGBA 原始位元陣列。以一張 iPhone 4800 萬像素的照片為例：`8000 像素 × 6000 像素 × 4 位元組 (RGBA) ≈ 192 MB`！ 這意味著如果您同時解碼 10 張照片，記憶體瞬間就會被吞噬將近 2GB！若一口氣解碼 100 張，瀏覽器分頁絕對會無可避免地崩潰崩潰。

為了解決記憶體暴增難題，OmniConvert 採用了**循序非同步工作佇列 (Sequential Queue)** 與**即時資源釋放機制**： 1. **單一處理通道**：檔案不會一次全部解碼，而是依序或受控地由 Web Worker 排隊處理。 2. **即刻釋放**：每處理完一張圖片並壓製為目標格式（例如 WebP）後，系統立即調用 `URL.revokeObjectURL()` 並主動清理暫存的 Canvas 像素矩陣，促使瀏覽器的垃圾回收機制 (Garbage Collection) 即時回收這 192MB 的巨大記憶體。 3. **二進位串流寫入**：完成的目標資料立即以小塊 Blob 寫入 JSZip 容器中，記憶體佔用始終維持在數十 MB 的極安全區間。

在原生瀏覽器使用 JavaScript 動態觸發多檔下載時，Chromium 核心常會將非安全點擊的下載直接靜默封鎖，甚至會將中文檔名轉為隨機亂碼 UUID。 OmniConvert 深度整合了工業級的 `file-saver` 引擎與相容封裝，將所有完成的檔案統一裝載至單一 ZIP 容器內，並精確保留原始檔案命名結構，讓您點擊一次就能帶走整批乾淨整齊的成果。