structuredclone通过引擎原生实现结构化克隆算法，对date、regexp等内置对象重建实例并保留原型链，对map/set等还原引用关系，对循环引用用映射表避免递归，对blob等调用底层接口直复制二进制，从而保类型保语义。
structuredClone 不是简单遍历复制，而是基于浏览器底层实现的结构化克隆算法（Structured Clone Algorithm），它在序列化、传输、反序列化三个阶段协同工作，兼顾类型保真与跨线程安全。
它是怎么做到“保类型+保语义”的？
传统 JSON 方案把 Date 变成字符串、RegExp 变成空对象、Map/Set 直接丢失——因为 JSON 标准只定义了有限几种可序列化的类型。structuredClone 则由引擎原生支持，对每种合法类型有专属处理逻辑：
- Date、RegExp、BigInt 等内置对象：不转字符串，直接重建实例，原型链和内部属性（如 RegExp 的 flags）完整保留
- Map、Set、TypedArray、ArrayBuffer：逐项复制键值或字节，同时还原引用关系（比如 Map 中的 key 是对象，克隆后仍保持对应关系）
- 循环引用：算法内部维护“已访问对象映射表”，遇到重复引用时复用已生成的克隆节点，避免无限递归或数据错乱
- Blob、File、ImageData 等 Web API 类型：调用底层平台接口直接复制二进制内容，不经过 JS 层编码解码
为什么比 JSON.parse(JSON.stringify()) 快？
关键在于绕过了文本中间态：
- JSON 方案需先将整个对象树序列化为字符串（内存分配 + UTF-8 编码），再解析成新对象（语法分析 + 对象重建），两轮开销叠加
- structuredClone 在 C++ 引擎层直接操作 JS 值的内部表示，跳过字符串转换，时间复杂度接近 O(n)，尤其在大数据量（如 10MB ArrayBuffer）时优势明显
- 实测：克隆含 5 层嵌套、10 万个元素的数组，structuredClone 平均耗时比 JSON 方案低 40%~60%（Chrome 125 环境下）
transfer 选项不是“优化”，而是内存模型切换
它不加速拷贝，而是改变数据归属：
- 普通克隆：源 ArrayBuffer 和克隆体各占一份内存，总占用翻倍
- 启用 transfer：原始 buffer 立即失效（byteLength 变 0），克隆体获得该内存块所有权，主线程无法再读写——这是零拷贝（O(1) 时间）的代价
- 典型场景：向 Web Worker 传视频帧数据，用 transfer 避免主线程多占百 MB 内存，但必须确保传完不再访问原 buffer
它的性能边界在哪？
高效不等于万能，瓶颈取决于数据特征：
- 小对象（
- 大 ArrayBuffer / TypedArray：transfer 能极大降低内存压力，但需业务层协调所有权
- 深度嵌套（>100 层）或超多引用（如图结构）：算法需维护映射表，内存占用略升，但不会栈溢出
- 不支持类型触发 DataCloneError：函数、DOM 节点、Proxy 等会立即报错，不消耗 CPU 做无效遍历
