structuredclone 不规避循环引用死锁，而是直接禁止：检测到循环即抛 datacloneerror，不维护引用图谱、不缓存、不降级，仅适用于无循环的纯数据场景。
structuredClone 本身不会“规避”循环引用死锁，因为它根本不会陷入死锁——它直接拒绝处理循环引用，抛出 DataCloneError。所谓“规避死锁”，其实是误解了它的行为机制：它不递归、不追踪、不缓存，而是按 HTML 标准做线性序列化，遇到循环就终止。真要安全处理循环引用，得换思路。
structuredClone 的真实限制
它不是“规避”循环引用，而是明确禁止：
- 设计上不维护对象引用图谱，只走单向遍历路径
- 一旦检测到同一对象被重复访问（如
a.b = a），立即中止并报错DOMException: An object could not be cloned - 错误不提示具体位置，只在顶层失败，调试困难
- 不兼容旧环境（Safari ReferenceError
需要循环引用复现时，structuredClone 不适用
如果你的场景要求克隆后仍保持 obj.self === obj 或 node.parent === parent 这类双向关系，structuredClone 无法满足：
- 它不重建引用关系，而是直接中断
- Map/Set 中含循环键值？同样报错，不会降级处理
- 哪怕只是
const x = {}; x.x = x;，也会失败
真正能处理循环引用的安全方案
用带 WeakMap 缓存的手动遍历，可控、透明、可扩展：
- WeakMap 存原始对象 → 克隆对象映射，避免内存泄漏
- 递归前先查缓存，命中则直接返回，彻底切断无限调用链
- 可按需支持 Date、RegExp、Map、Set、TypedArray 等类型
- 对万级节点树，实测耗时仍在毫秒级，性能足够实用
什么时候该坚持用 structuredClone
仅当你的数据天然无循环，且需高效拷贝复杂类型时才推荐：
- WebSocket 收到的纯数据消息（JSON-like 但含 ArrayBuffer/BigInt）
- 跨 iframe / Worker 的 postMessage 通信载荷
- Redux DevTools 快照（前提是 state 设计上已规避双向引用）
- 确认运行环境支持（Chrome 98+、Firefox 94+、Node.js 17.0+）
