别再用 JSON.parse 深拷贝了，聊聊 StructuredClone

临近下班，我们业务线出了一个极度无语的线上 Bug。

产品侧反馈，在一个非常核心的财务表单里，用户明明选择了 2026-04-14 作为结算日期，但点击提交后，整个页面直接白屏崩溃。

我打开错误监控看了一眼日志，立刻就把组里那个刚入职不久的小伙子叫了过来。原因极其经典：他在把表单的原始状态同步给历史快照时，为了图省事，顺手写了一段几乎所有前端都写过的代码：

js 复制代码

// 模拟用户表单数据
const formData = {
  amount: 1000,
  date: new Date("2026-04-14"), // 用户选的结算日期（Date对象）
};

// 深拷贝
const snapshot = JSON.parse(JSON.stringify(formData));

console.log("原始:", formData.date, typeof formData.date); 
// Date object

console.log("快照:", snapshot.date, typeof snapshot.date); 
// "2026-04-14T00:00:00.000Z" string

// 后续业务代码
function calcSettlementTime(data) {
  // 这里默认 date 是 Date 对象
  return data.date.getTime();
}

// 页面直接崩溃😢
try {
  const time = calcSettlementTime(snapshot);
  console.log("时间戳:", time);
} catch (err) {
  console.error("页面崩溃:", err);
}

他满脸委屈：老大，大家平时深拷贝不都是这么写的吗？🤷‍♂️

我让他自己把这段代码在控制台跑一遍。当他看到表单里原本好好的 Date 对象，经过这一进一出，硬生生变成了一串 ISO 格式的字符串 ，导致后面调用 snapshot.date.getTime() 直接抛出 TypeError 时，他自己也沉默了。

作为前端老油条，这种因为 JSON.parse(JSON.stringify()) 引发的血案，我见过太多了。它不仅会把 Date 变成字符串，还会把 Map 和 Set 变成空对象 {}，会把 undefined、Symbol 以及函数直接活生生抹除，更别提遇到循环引用时，它会当场抛出异常让你的主线程直接崩溃。

以前，我们为了解决这个破事，不得不在每个项目里老老实实 npm install lodash，然后引入那个笨重的 cloneDeep。

但现在是 2026 年了。浏览器早就原生内置了完美的终极解药------structuredClone。

今天咱们不聊虚的架构，就花三分钟，把这个原生 API 的底层逻辑讲清楚。

它是怎么解决历史遗留问题的？

structuredClone 不是什么语法糖，它是浏览器底层暴露出来的 结构化克隆算法（Structured Clone Algorithm）。这就意味着，它在 C++ 引擎层面的处理逻辑，远比 JS 业务层面的递归拷贝要深得多。

看一下原生 API 的用法：

javascript 复制代码

const original = {
  date: new Date(),
  set: new Set([1, 2, 3]),
  map: new Map([['key', 'value']]),
  regex: /hello/i,
  buffer: new Uint8Array([1, 2, 3]).buffer,
};

// 制造一个循环引用
original.self = original;

// 一行代码，原生搞定
const cloned = structuredClone(original);

console.log(cloned.date instanceof Date); // true
console.log(cloned.set instanceof Set);   // true
console.log(cloned.self === cloned);      // true 完美处理循环引用！

发现没有？它不仅完美保留了所有的内置对象类型，连 JSON.parse 绝对搞不定的循环引用，它都处理得游刃有余。由于是在引擎底层运行，不需要像 Lodash 那样在 JS 运行时里疯狂压栈递归，它的执行效率在大部分复杂场景下都具有压倒性优势👍👍👍。

零拷贝转移（Transferable Objects）

如果你以为 structuredClone 只是为了少引入一个 Lodash，那你就太小看浏览器的底层野心了。

它藏着一个 90% 的前端都不知道的极其硬核的功能：内存转移（Transfer）。

在前端处理音视频、WebGL、或者读取几十 MB 的大文件时，我们经常会生成巨大的 ArrayBuffer。如果你用传统的深拷贝，内存瞬间翻倍，几十兆的内存分配极容易引起页面的掉帧卡顿。

structuredClone 提供了一个极其变态的第二个参数配置：{ transfer }。

javascript 复制代码

// 假设这是一个极大的 50MB 数据内存块
const u8Array = new Uint8Array(1024 * 1024 * 50);
const hugeBuffer = u8Array.buffer;

// 传统的深拷贝：内存翻倍，耗时极长
// const badCopy = lodash.cloneDeep(hugeBuffer); 

// 直接内存转移
const fastClone = structuredClone(hugeBuffer, { transfer: [hugeBuffer] });

console.log(fastClone.byteLength); // 52428800 (50MB 完美转移)
console.log(hugeBuffer.byteLength); // 0 (原对象的内存地址被转移)

这段代码的核心在于：它压根没有复制数据。 它直接在内存层面，把这块 50MB 数据的所有权，从 hugeBuffer 强行转移给了 fastClone。原对象被彻底掏空（变成了 detached 状态）。

这种零拷贝机制，在结合 Web Worker 处理复杂后台计算时，是打破性能瓶颈的绝对神器。这是任何第三方 JS 库都做不到的底层API。

一些坑要讲清楚🤔

既然这么牛，是不是以后项目里所有的拷贝闭着眼睛用它就行了？作为一个踩过无数坑的老兵，我必须点出它的几个致命死角。如果你在真实的业务架构里滥用，下场比用 JSON.parse 还要惨。

对于函数和 DOM 节点的处理

JSON.parse 遇到函数，它会默默地忽略掉，至少不报错。但 structuredClone 很直接。只要你的对象树里藏着一个方法，或者藏着一个 DOM 节点的引用，它会直接给你抛出 DataCloneError。

javascript 复制代码

const objWithFunc = {
  data: 123,
  onClick: () => console.log('click')
};

// 只要带有函数，直接抛同步错误
// DOMException: () => console.log('click') could not be cloned.
const copy = structuredClone(objWithFunc);

这就意味着，如果你要拷贝的是一个 Vue/React 的响应式组件实例，或者是带有业务方法的数据模型，绝对不能用它👋。

原型链的断裂

不管你原本是一个通过 class 实例化的多么高级的业务对象，经过 structuredClone 的洗礼后，它都会变成一个普通的纯对象（Plain Object）。

javascript 复制代码

class User {
  constructor(name) { this.name = name; }
  sayHi() { console.log('hi'); }
}

const user = new User('前端');
const cloneUser = structuredClone(user);

console.log(cloneUser instanceof User); // false 
cloneUser.sayHi(); // TypeError: cloneUser.sayHi is not a function

原型链上的所有方法全部丢失。它只关心纯粹的数据，不关心你的面向对象架构。'

需要时收藏起来⭐⭐⭐

这几年，前端的工具链卷得飞起，大家的 package.json 越来越臃肿。遇到数组去重找库，遇到时间格式化找库，遇到深拷贝也要找库。

如果你只是单纯地处理一些后端传过来的嵌套数据，或者表单的复杂配置结构，完全可以直接把 structuredClone 敲在你的代码里。不用担心兼容性，目前主流浏览器（包括 Node.js）的支持率早就达到了工业级使用的标准了。

下次 Code Review 时，别再让我看到满屏的 JSON.parse 了（玩笑😁😁😁）。

分享完毕，谢谢大家🙌

别再用 JSON.parse 深拷贝了，聊聊 StructuredClone

它是怎么解决历史遗留问题的？

零拷贝转移 （Transferable Objects）

一些坑要讲清楚🤔

需要时收藏起来⭐⭐⭐

零拷贝转移（Transferable Objects）