详细解析JavaScript中JSON.stringify无法处理循环引用的底层原理

在日常 JavaScript 开发中，不少开发者都踩过这样一个经典报错：当使用 JSON.stringify 对包含循环引用的对象进行序列化时，程序会立即抛出异常并终止运行。这背后的原因并非代码缺陷，而是底层机制与规范双重限制下的必然结果。

这一现象的根本原因在于：JSON.stringify 是一个无状态函数，它不具备记录已访问对象的“记忆”能力。当遇到重复引用时，它无法识别出这种循环依赖，只能持续向下深入，最终导致调用栈溢出。

深度优先遍历 + 无状态检查 = 必然崩溃

JSON.stringify 底层采用深度优先策略递归遍历每个属性值。当它进入一个对象时，会试图访问其所有可枚举属性；若其中某个属性指向了此前已处理过的对象（如父节点、自身或中间层级的引用），由于缺乏状态追踪机制，它会将该对象视为全新节点并再次递归进入。这种无状态检查最终形成了无限递归，迅速耗尽调用栈空间，JavaScript 引擎只能抛出 TypeError: Converting circular structure to JSON 来强制中断，避免进程完全卡死。

JSON 格式本身就不支持循环结构

从规范层面来看，标准 JSON 是一种纯数据交换格式，其设计目标仅限于表达树状结构，既不支持指针概念，也不包含类似 $ref 的元数据来表述“指向前面第 N 个对象的引用”。因此，即使 JavaScript 引擎试图容忍循环引用，也无法在合法的 JSON 字符串中表达这种关系。换句话说，这并不是实现层面的偷懒，而是 JSON 规范在语义层面天然排斥循环结构。

为什么 WeakMap 能解决，而普通 Map 不行？

任何能够安全处理循环引用的深拷贝或序列化方案（例如 flatted 库或自定义 deepClone 函数），其核心都依赖于 WeakMap 来建立已访问对象的注册表。WeakMap 具备以下关键特性：

• 键必须为对象，且不会阻止该对象被垃圾回收机制回收
• 能够精确判断某个原始对象是否已被处理，从而跳过重复递归
• 避免内存泄漏——临时缓存会随原始对象的释放而自动清理

换成普通 Map 虽然同样可以实现记录功能，但其强引用特性会导致对象无法被及时释放。在长期运行的前端应用中，这种做法会悄然累积内存压力，实际项目中也因此产生过不少性能问题。

浏览器原生 structuredClone 是个例外

现代浏览器提供的 structuredClone() API 能够直接处理循环引用，其底层依赖 V8 引擎的克隆算法，内置了对象图遍历与引用映射机制，本质上与 flatted 的思路一致，只是封装得更加底层且透明。不过，它生成的是对象副本而非 JSON 字符串，且不支持函数、undefined 等非可序列化值，适用场景相对有限。如果你需要进行深拷贝且对象包含循环引用，它无疑是首选方案；但如果必须输出 JSON 格式，仍然需要借助 flatted 这类库手动实现。