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

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

前端代碼里到處都是“復(fù)制”：

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

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

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

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

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

偽代碼：

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

調(diào)用后 hugeBuffer.byteLength === 0，內(nèi)存已“搬家”，原線程再訪問就報錯。

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; // 隨便改點數(shù)據(jù)
    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 瞬間歸零，內(nèi)存曲線平滑
• Worker 接收到的 是同一塊物理內(nèi)存，無需拷貝即可讀寫
• 回傳時再次轉(zhuǎn)移，主線程重新拿到所有權(quán)

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

測試數(shù)據(jù)：200 MB Float64Array機器：MacBook Air M2 / Chrome 126

結(jié)論：速度提升 20~70 倍，內(nèi)存零增長；數(shù)據(jù)越大，差距越夸張。

5. 四大實戰(zhàn)場景

5.1 Worker 計算“大圖直方圖”

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

5.2 大文件分片上傳

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

注：Fetch 對請求體尚未直接暴露轉(zhuǎn)移能力，但 ServiceWorker 與 postMessage 可以，先做內(nèi)存級優(yōu)化。

5.3 WebAssembly 內(nèi)存快照

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

游戲引擎常用：玩家回檔時瞬間恢復(fù)線性內(nèi)存，避免重新 malloc。

5.4 跨 Tab 共享內(nèi)存 + Atomics

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

6. transfer語法

7. 常見坑位匯總

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

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

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

8. 提速 30% 的技巧：批量轉(zhuǎn)移

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

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

瀏覽器底層會一次性 map 重映射 內(nèi)存區(qū)域，比多次單獨轉(zhuǎn)移再 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; }
}

不支持就回退到“復(fù)制”或拆分任務(wù)，保證業(yè)務(wù)邏輯繼續(xù)跑。

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

• 這段內(nèi)存后面還會用嗎？→ 不用 → 直接轉(zhuǎn)移
• 接收方需要同一塊物理內(nèi)存？→ 是 → 轉(zhuǎn)移
• 數(shù)據(jù) > 16 MB？→ 是 → 轉(zhuǎn)移（Chrome 大對象分配閾值）
• 目標(biāo)環(huán)境不支持？→ 檢測 + 回退

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