JavaScript structuredClone 复制 Map 和 Set 时如何保留类型

如果目标是把一个包含 Map 和 Set 的对象完整复制出来，直接使用 structuredClone(value) 即可：集合本身会保留为对应类型，嵌套对象会被深复制，原对象和新对象不会共享这些可克隆引用。真正容易踩坑的是“保留类型”不等于“恢复所有运行时能力”：自定义原型、访问器、私有字段和函数都不应当默认保留。

官方资料：https://developer.mozilla.org/zh-CN/docs/Web/API/Web_Workers_API/Structured_clone_algorithm

先确认 structuredClone 的保留范围

structuredClone 使用结构化克隆算法返回深复制结果。对常见的 Map、Set、数组、日期和普通对象，它会识别内建类型并创建新的对应容器；集合里的对象值也会继续递归复制。因此，判断“类型保留”至少要拆成三件事：容器品牌是否保留、数据是否完整、嵌套引用是否已经脱离原对象。

它不是实例序列化器。原型链、属性描述符、getter/setter 等元数据不会按原样搬过去。也就是说，业务类的行为方法、只存在于原型上的能力和私有字段，不能靠一次 structuredClone 自动恢复。

用最小样例验证 Map 与 Set

先把断言写在复制动作旁边，避免只打印集合内容而误判。下面的代码同时覆盖类型、数量、内容和对象身份：

const original = {
  cache: new Map([
    ["user:1", { name: "林墨", roles: ["editor"] }],
  ]),
  tags: new Set(["javascript", "clone"]),
};

// 复制整个数据图；Map、Set 和其中的普通对象会递归处理。
const clone = structuredClone(original);

// 先验收容器类型和基本内容，再检查引用是否独立。
console.assert(clone.cache instanceof Map);
console.assert(clone.tags instanceof Set);
console.assert(clone.cache.size === 1 && clone.tags.has("clone"));
console.assert(clone !== original);
console.assert(clone.cache !== original.cache);
console.assert(clone.tags !== original.tags);

这里的关键不是把 Map 转成键值数组再转回来，而是让结构化克隆算法直接处理它。constructor === Map 也可以作为补充检查，但跨 realm 场景优先使用合适的类型判断策略，避免把构造函数身份当成唯一依据。

处理嵌套值与共享引用

深复制的验收重点在集合内部。假设一个对象同时被 Map 的值和 Set 的元素引用，克隆后这两个入口应该共同指向“克隆出来的同一个对象”，而不是各自生成一份，也不能回指原对象：

const shared = { enabled: true };
const original = {
  records: new Map([["feature", { config: shared }]]),
  objects: new Set([shared]),
};

// 保留数据图中的共享关系，同时隔离原图和新图。
const clone = structuredClone(original);
const fromMap = clone.records.get("feature").config;
const fromSet = [...clone.objects][0];

// 两个入口应共享克隆节点，但不能碰到原节点。
console.assert(fromMap === fromSet);
console.assert(fromMap !== shared);

这个检查比 JSON.stringify 后比较字符串更有价值，因为它验证了引用图。Map 的键和值、Set 的元素都可能是对象；只看 size 或控制台展开结果，无法证明它们已经与原数据隔离。

识别不能保留的类型与元数据

如果 Map 的键、值或 Set 的元素中混入函数、Symbol、DOM 节点等不可序列化成员，调用可能抛出 DataCloneError。因此生产代码可以把复制动作放进明确的错误边界：

function cloneState(state) {
  try {
    // 让调用方收到可识别的复制失败，而不是拿到半成品状态。
    return structuredClone(state);
  } catch (error) {
    // 只补充上下文；不要吞掉原始异常或静默改用 JSON。
    throw new Error("状态包含不可结构化克隆的成员", { cause: error });
  }
}

自定义类也要单独验收。克隆结果可能保留字段数据，却不再是原来的类实例；依赖方法、原型判断或私有字段的对象，应改成显式的 DTO 转换和重新构造，而不是把 instanceof 失败当成偶发问题。

给旧环境安排兼容策略

先检测能力，再决定是否继续：

// 能力检测放在真正复制之前，便于快速失败或走已评估的兼容实现。
if (typeof structuredClone !== "function") {
  throw new Error("当前 JavaScript 宿主不支持 structuredClone");
}

const nextState = structuredClone(currentState);

不要用 JSON.parse(JSON.stringify(value)) 作为 Map/Set 的通用回退：Map 和 Set 会失去容器语义，日期、undefined、循环引用等也有不同的损失。若必须支持旧浏览器，应评估 polyfill 的覆盖范围，或针对领域数据明确写出 Map、Set 的转换协议并配套测试。

用检查清单完成迁移验收

按这五项验收，才能回答“Map 和 Set 是否保留类型”。一句话收束：能被结构化克隆的内建集合可以保留容器类型，但业务对象的行为和不可序列化成员仍要由应用自己设计。

常见问题

structuredClone 会让原 Map 和 Set 失效吗？

普通复制不会，原容器仍可读取和修改。只有使用 transfer 处理可转移对象时，相关资源才可能从原对象移走；Map 和 Set 本身不属于这种转移资源。

为什么复制后 Map 的对象值改了，原对象没有变化？

这是深复制的预期结果。Map 容器和其中可克隆的对象值都拥有新引用，所以应通过内容断言和身份断言一起确认。

如何保留自定义类实例的方法？

不要依赖 structuredClone 恢复原型。先把实例转换为明确的数据对象，克隆后再用构造函数或工厂方法重建，并为私有字段和方法行为写测试。