100 MB 文件 0 內存增長、PostMessage 秒傳、WebAssembly 零開銷，全靠這把“隱形鑰匙 Transferable”。

1. 為什么你總在“復制”而不是“瞬移”？

前端代碼里到處都是“復制”：

• Worker 里算完數據回傳主線程
• 表單快照深拷貝防臟值
• 大文件 ArrayBuffer 切片上傳

傳統做法 = 瀏覽器再開一塊內存 → 把字節逐一拷過去 → 老內存等待 GC。內存峰值翻倍，時間 O(n)，GC 還要再掃一遍。

Transferable 的存在就是讓你把“復印件”變成“原件快遞”：原對象直接失效，內存所有權瞬移，沒有第二次分配，也沒有 GC 壓力。

2. 什么是 Transferable？一句話速通

• 是 能力 而不是新類型：只要實現了 Transferable 接口，就可以被標記為“可轉移”
• 目前瀏覽器暴露的實例只有兩類：– ArrayBuffer– MessagePort（本文不展開，用于跨線程通信）
• 使用場景： postMessage 和 structuredClone 的第二個參數

偽代碼：

worker.postMessage(hugeBuffer, [hugeBuffer]); // 第二項 = 轉移列表

調用后 hugeBuffer.byteLength === 0，內存已“搬家”，原線程再訪問就報錯。

3. 先跑個 Demo：15 行代碼看效果

<script>
const buf = new ArrayBuffer(100 * 1024 * 1024); // 100 MB
const worker = new Worker(URL.createObjectURL(new Blob([`
  self.onmessage = e => {
    const t0 = performance.now();
    const arr = new Uint8Array(e.data);
    arr[0] = 1; // 隨便改點數據
    self.postMessage(arr.buffer, [arr.buffer]);
  };
`], { type: 'application/javascript' })));

console.log('Before:', buf.byteLength); // 104857600
worker.postMessage(buf, [buf]);
console.log('After:', buf.byteLength);  // 0
</script>

要點

• 主線程 100 MB 瞬間歸零，內存曲線平滑
• Worker 接收到的 是同一塊物理內存，無需拷貝即可讀寫
• 回傳時再次轉移，主線程重新拿到所有權

4. 性能對比：Transfer vs 深拷貝

測試數據：200 MB Float64Array機器：MacBook Air M2 / Chrome 126

結論：速度提升 20~70 倍，內存零增長；數據越大，差距越夸張。

5. 四大實戰場景

5.1 Worker 計算“大圖直方圖”

把 ImageData 的 data.buffer 丟給 Worker，算法跑完再把結果 buffer 轉回主線程展示。好處：UI 線程 0 阻塞，還能邊算邊播動畫。

5.2 大文件分片上傳

const chunk = file.slice(start, end).arrayBuffer(); // 返回 ArrayBuffer
await fetch('/upload', {
  method : 'POST',
  body   : chunk, // 傳統：復制到 JS 堆 → XHR 再復制 → 內核
  // 借助 Fetch 的 Stream + Transferable*（實驗）可進一步 0 拷貝
});

注：Fetch 對請求體尚未直接暴露轉移能力，但 ServiceWorker 與 postMessage 可以，先做內存級優化。

5.3 WebAssembly 內存快照

const mem = wasmInstance.exports.memory.buffer;
const snap = structuredClone(mem, [mem]);

游戲引擎常用：玩家回檔時瞬間恢復線性內存，避免重新 malloc。

5.4 跨 Tab 共享內存 + Atomics

結合 SharedArrayBuffer（需 COOP/COEP 頭部）與 MessagePort，可以實現 多 Tab 讀寫同一塊內存，還能用 Atomics.wait/notify 做同步鎖。Transferable 負責把 MessagePort 送到新 Tab，完成“握手”。

6. transfer語法

7. 常見坑位匯總

• 轉移后原對象立即可用？否。ArrayBuffer.byteLength === 0，再訪問拋 DOMException: ArrayBuffer is detached
• TypedArray 與 Buffer 的關系
  Uint8Array 只是 視圖，轉移時要針對 array.buffer，否則只復制了“索引”
• 誤把普通對象塞進列表

postMessage({data: buf}, [buf]); // ?
 postMessage({data: buf}, [{data: buf}]); // ? 數組里不是 Transferable

• Node 環境Node ≥ 17 才有 structuredClone，但 worker_threads.postMessage 同樣支持轉移，語法與瀏覽器一致
• 大小端 & 共享內存
  SharedArrayBuffer 不可被轉移，只能共享；別混淆二者使用場景。

8. 提速 30% 的技巧：批量轉移

如果有 幾十個小 Buffer（加密分包、WebRTC 幀），可以一次性推進數組：

const transfers = packets.map(p => p.buffer);
worker.postMessage(packets, transfers);

瀏覽器底層會一次性 map 重映射 內存區域，比多次單獨轉移再 GC 更快。

9. 檢測與回退：不讓老瀏覽器白屏

function canTransfer() {
  try {
    const ab = new ArrayBuffer(1);
    const { port1 } = new MessageChannel();
    port1.postMessage(ab, [ab]);
    return ab.byteLength === 0;
  } catch { return false; }
}

不支持就回退到“復制”或拆分任務，保證業務邏輯繼續跑。

10. 遇到大 Buffer 先問自己 4 句

• 這段內存后面還會用嗎？→ 不用 → 直接轉移
• 接收方需要同一塊物理內存？→ 是 → 轉移
• 數據 > 16 MB？→ 是 → 轉移（Chrome 大對象分配閾值）
• 目標環境不支持？→ 檢測 + 回退

Transferable 不是“新框架”，也不是“語法糖”，而是瀏覽器留給前端的一把“隱形鑰匙”——用不用，它都在那里；一旦用了，100 MB 數據就像“瞬移”一樣，眨眼功夫出現在另一個線程，而你的內存曲線，連波動都沒有。