在 JavaScript 开发中，JSON.stringify 是数据交换与调试的常用工具，但面对 Set 对象时，它却会“悄然失效”——直接返回一个空对象 {}。这并非因为它“识别”了 Set，而是由于它无法解析 Set 的内部结构，最终只能交出一份无效的“白卷”。

为什么 Set 会变成 {}

问题的根源在于 JSON.stringify 的底层机制：它只能序列化标准的、可枚举的自有属性，且仅支持基本类型、数组和普通对象。而 Set 对象由内置构造函数创建，其核心数据（通过 .add() 添加的元素）被存储在引擎内部的、不可枚举的 [[Entries]] 槽中。

这导致了一个尴尬的局面：当你尝试序列化一个 Set 时，JSON.stringify 遍历所有属性后，发现该对象“空无一物”，没有任何它可以处理的属性。于是，它便返回了一个空对象的字符串形式。

console.log(JSON.stringify(new Set())); // "{}"
console.log(JSON.stringify(new Set([1, 2]))); // "{}"

无论 Set 是空的还是包含数据，输出结果完全相同——一个孤零零的 {}。

这个坑带来的实际问题

这种静默转换会引发一系列隐蔽的 bug：

• 误判数据状态：如果你习惯用 JSON.stringify(obj) === '{}' 来判断对象是否为空，那么一个刚初始化、待接收数据的 Set 将被错误地判为空对象。
• 深拷贝彻底失效：试图用 JSON.parse(JSON.stringify(mySet)) 快速深拷贝？结果只会得到一个普通空对象 {}，Set 结构及其数据全部丢失。
• 调试时的困惑：在日志或控制台中看到一个 {}，你可能误以为它是一个普通空对象，难以意识到它原本是一个无法通过 JSON 还原的 Set 实例。

如何安全识别和处理 Set

要避开这个陷阱，关键在于使用正确的方法来识别和操作 Set：

• 类型判断用 instanceof：这是最可靠的方式。obj instanceof Set 能明确告知你对象的真实类型。
• 序列化前主动转换：如需将 Set 转为 JSON 字符串，必须手动将其转为数组：JSON.stringify(Array.from(mySet))。
• 空值检查分情况：检查 Set 是否为空，应使用 mySet.size === 0。
• 封装统一工具函数：对于需要通用判断“逻辑空值”的场景，建议封装一个函数，根据类型分别处理：

  function isEmpty(value) {
    if (value instanceof Set || value instanceof Map) return value.size === 0;
    if (Array.isArray(value)) return value.length === 0;
    if (value && typeof value === 'object') return Object.keys(value).length === 0;
    // ... 其他类型处理
  }

延伸提醒：其他类似“隐身”类型

Set 并非个例，JavaScript 中还有一批“特殊对象”在 JSON.stringify 面前存在类似问题：

JSON.stringify(new Map()); // "{}"
JSON.stringify(new Date()); // 日期字符串（这是特例，有默认转换）
JSON.stringify(/abc/); // "{}"
JSON.stringify(BigInt(123)); // 直接报错：Uncaught TypeError

对于 Map、正则表达式等类型，它们同样无法被正确序列化。而 BigInt 则更加极端，直接导致序列化过程抛出错误。因此，一个重要的原则是：永远不要依赖 JSON.stringify 的结果来做这些特殊类型的类型判断或空值校验。正确的类型检查与数据转换，始终是编码中需要手动把控的细节。