json.stringify遇循环引用直接报错，因无法处理对象自引用；解决需用weakmap记录路径并截断，或改用structuredclone（现代环境）及白名单字段提取。
JSON.stringify 遇到循环引用直接报错
遇到 TypeError: Converting circular structure to JSON 就是典型信号：某个对象的某个属性，最终又指向了自己（比如 parent.children[0].parent === parent）。JSON.stringify 默认不处理这种结构，连尝试都不做，直接抛错。
常见场景包括树形结构（节点带 parent 指针）、双向 Map、Vue/React 组件实例（内部有上下文引用链）、甚至简单的对象互相赋值：
const a = {}; const b = {}; a.ref = b; b.ref = a; JSON.stringify(a); // 报错
解决思路不是“绕开”，而是主动截断引用链。最轻量的做法是传入自定义 replacer 函数：
- 检查当前值是否已出现在遍历路径中（用 WeakMap 记录「对象 → 路径」）
- 若重复出现，返回
null或占位字符串（如"[Circular]"） - 注意：不能用普通 Object 做缓存，否则会阻止 GC；WeakMap 是唯一安全选择
toString 方法被意外触发导致栈溢出
很多调试场景下会隐式调用 toString，比如 console.log(obj)、拼接字符串 '' + obj、甚至某些库的错误信息生成。如果 toString 里手动递归访问子属性（例如打印整个树），而对象存在循环引用，就会无限深入，最终 RangeError: Maximum call stack size exceeded。
关键区别在于：这不是 JSON 序列化问题，而是你写的逻辑本身没设防。
- 避免在
toString中深度遍历嵌套结构；改用浅层摘要，比如`Node(${this.id})` - 如果必须展示结构，加递归深度限制（如默认最多 2 层），并用 Set 记录已访问对象
- 切勿在
toString里调用JSON.stringify(this)—— 这等于把两个坑叠在一起
使用 structuredClone 处理循环引用（仅现代环境）
structuredClone 是目前唯一原生支持循环引用的深拷贝方法，它底层用的是结构化克隆算法（与 postMessage 同源），能自动识别并复用已克隆的对象。
但它不是万能解药：
- 只支持可结构化克隆的类型（Date、RegExp、Array、Object、Map、Set 等），不支持 function、undefined、Symbol、Promise、Error
- Node.js 17+ 才稳定支持；Chrome 98+、Firefox 94+、Safari 15.4+；旧环境必须降级处理
- 它不解决序列化需求——
structuredClone返回新对象，不是字符串；要转 JSON 还得再过一遍JSON.stringify，此时仍需防循环
自定义序列化器必须区分「调试用」和「传输用」
开发时希望看到尽可能多的结构信息（哪怕带 [Circular]），但生产环境序列化用于 API 传输时，字段必须确定、可预测、无副作用。
建议拆成两套逻辑：
- 调试用：
console.dir(obj, { depth: null, colors: true })—— 利用浏览器/Node 内置的循环检测能力 - 传输用：显式定义白名单字段，用
pick类工具（如 Lodash 的pick）提取，彻底避开嵌套对象遍历 - 永远不要依赖
obj.toString()或JSON.stringify(obj)做业务数据输出；它们是调试辅助，不是序列化协议
循环引用本身不是 bug，是数据建模的自然结果；真正的问题在于，我们常把「能打印出来」等同于「能安全序列化」，而这两件事的技术约束完全不同。
