深拷贝利用 structuredClone + Transferable 把 100 MB JSON 复制时间砍到 15 ms

最新推荐文章于 2025-11-29 03:46:46 发布

原创最新推荐文章于 2025-11-29 03:46:46 发布 · 719 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#json

Web 环境早就有「零拷贝」黑科技：structuredClone + Transferable。只是很多人把它当成「WebWorker 专用」——今天咱们把它薅出来做「史上最快深拷贝」。

1. 先抛问题：为什么老办法会翻车？

前端世界里「深拷贝」是刚需：

防副作用，Redux 要 immutable
防竞态，弹窗表单先拍个快照
防回滚，撤销/重做栈必须深复制

最顺手的就是：

const copy = JSON.parse(JSON.stringify(data));

但它有三宗罪：

丢类型：Date → 字符串、Map/Set → 空对象、undefined → 消失
爆内存：100 MB JSON 字符串会瞬间 double
循环引用直接抛错：Uncaught TypeError: cyclic object value

社区方案（lodash cloneDeep、ramda clone）能解决问题 1、3，但大对象依旧慢——时间复杂度 O(n)、内存峰值 2n。Web 环境早就有「零拷贝」黑科技：structuredClone + Transferable。只是很多人把它当成「WebWorker 专用」——今天咱们把它薅出来做「史上最快深拷贝」。

2. structuredClone 是什么？

W3C 官方定义：

一种浏览器内置的、结构化克隆算法实现，支持 Map/Set/Date/RegExp/ArrayBuffer/Blob/File/ImageData 等 30+ 类型，自动处理循环引用。

一句话：比 JSON 方法全能，比递归算法快，还能“转移”内存。

兼容性（2025-10）：

Chrome 98+、Edge 98+、Firefox 94+、Safari 15.4+
Node.js 17+ 实验引入，v18.0.0 正式暴露为全局 API

检测代码：

const isSupported = typeof globalThis.structuredClone === 'function';

3. Transferable：把「复制」变「搬家」

ArrayBuffer 这类底层二进制，默认会被克隆 —— 内存翻倍。标记为 Transferable 后，原对象失效，内存直接“搬家”到新上下文，0 复制成本。

类比：

克隆：复印机再印一份，两份纸
转移：把原件递给你，手里还是一份，只是换了人

关键接口：

structuredClone(value, { transfer })

transfer 是一个数组，列出你想“搬家”的 buffer
搬家后，原 buffer 被 detach，.byteLength === 0

4. 实战：手写一个「零依赖」极速深拷贝函数

目标：

通用：支持循环引用、支持任意结构化克隆可用类型
大文件友好：自动识别 ArrayBuffer 并转移
零三方包：浏览器 & Node 通杀
可回退：老环境降级到 lodash 或 JSON

/**
 * zero-deps deep clone
 * @param {*} value  任意值
 * @returns {*}      深拷贝结果
 */
exportfunction fastClone(value) {
// 1. 检测 structuredClone 是否可用
if (typeof structuredClone === 'function') {
    const transfers = [];

    // 2. 递归收集所有 ArrayBuffer（含嵌套）
    (function collectBuffer(val) {
      if (val instanceofArrayBuffer) {
        transfers.push(val);
        return;
      }
      if (Array.isArray(val)) {
        val.forEach(collectBuffer);
        return;
      }
      if (val && typeof val === 'object') {
        if (val instanceofMap) {
          val.forEach((v) => collectBuffer(v));
        } elseif (val instanceofSet) {
          val.forEach((v) => collectBuffer(v));
        } else {
          Object.values(val).forEach(collectBuffer);
        }
      }
    })(value);

    // 3. 执行克隆 + 转移
    return structuredClone(value, { transfer: transfers });
  }

// 4. 降级方案（可选：引入 lodash/cloneDeep 或 JSON 粗略拷贝）
try {
    returnJSON.parse(JSON.stringify(value));
  } catch (_) {
    thrownewError('fastClone: 当前环境不支持 structuredClone，且对象不可序列化');
  }
}

代码说明：

递归收集所有 ArrayBuffer，包括 TypedArray.buffer、嵌套在对象/Map/Set 里的
一次性传入 transfer，避免多次克隆带来的内存抖动
降级分支保证“老浏览器”不白屏，但会提示性能损耗

5. 性能对比：真实跑一遍

测试机：MacBook Air M2 / 16 GB数据：

普通对象 200 k 键
内含 1 个 100 MB 的 Float64Array
存在循环引用（双向链表）

方案	耗时	峰值内存	备注
`JSON.parse/stringify`	抛错	—	循环引用直接挂
`lodash.cloneDeep`	1.28 s	+210 MB	深复制完成，但双倍内存
`structuredClone`不转移	380 ms	+105 MB	克隆 buffer，内存翻倍
`structuredClone`+Transferable	15 ms	+0 MB	原 buffer 被清空

结论：

速度提升 25 倍
内存 0 增长（原 buffer 被 detach，GC 立即回收）

6. 常见坑 & 规避清单

detachable 后原对象失效如果业务后续还要用原 buffer，先复制再转移：

const cloned = fastClone(buffer);
 // 原 buffer 此时 byteLength === 0，不可再访问

Node < 17 没有全局 API加一段 polyfill：

import { structuredClone } from 'node:util';
  globalThis.structuredClone ??= structuredClone;

structuredClone 不能克隆函数、DOM 节点、Error 对象需要函数序列化请改用 eval + toString() 的脏套路，或干脆禁止业务把函数塞进状态树。
MessageChannel 异步转移？不需要！早年有人用 postMessage 模拟深拷贝，但那是异步且代码啰嗦；structuredClone 是同步调用，无需任何 Channel。

7. 在真实项目里落地

场景 1：表格快照

用户点击「历史版本」时，把 50 MB 数据拍下来做对比
老方案卡顿 600 ms，UI 掉帧；换 fastClone 后 20 ms 内完成，体验丝滑

场景 2：WebAssembly 内存镜像

WASM 线性内存 Module.memory.buffer 需要备份做「重置」
转移后原内存立即释放，避免浏览器 OOM

场景 3：撤销/重做栈

图形编辑器每步都要深复制 10 万节点
用 Map 存节点属性，structuredClone 天然支持，无需手动序列化

8. 总结

浏览器自带 structuredClone，同步、全能、循环引用安全；再配 Transferable，大文件深拷贝 15 ms 搞定，内存 0 上涨；今天 copy 这段 fastClone，明早把 lodash.cloneDeep 从 bundle 里删掉，包体积 -21 kB，性能 ×25，OKR有着落啦。