登录
别再用 JSON.parse 深拷贝了，聊聊 StructuredClone
临近下班，我们业务线出了一个极度无语的线上 Bug。
产品侧反馈，在一个非常核心的财务表单里，用户明明选择了 2026-04-14 作为结算日期，但点击提交后，整个页面直接白屏崩溃。
我打开错误监控看了一眼日志，立刻就把组里那个刚入职不久的小伙子叫了过来。 原因极其经典：他在把表单的原始状态同步给历史快照时，为了图省事，顺手写了一段几乎所有前端都写过的代码：
// 模拟用户表单数据
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 的用法：
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 }。
// 假设这是一个极大的 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。
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）。
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 了 （玩笑😁😁😁）。
分享完毕，谢谢大家🙌
