识别循环引用导致的对象膨胀，关键在于提前确认结构是否可安全遍历；需通过WeakMap拓扑扫描、自反检查、引用关系比对、缓存命中率与递归深度监控、结构哈希树校验等方式综合防控。
识别循环引用导致的对象膨胀，关键不在于“发现异常”，而在于“提前确认结构是否可安全遍历”。深拷贝过程中的对象膨胀，本质是递归失控或缓存失效——拓扑结构一旦存在闭环，未经校验的拷贝逻辑会反复进入同一节点，造成内存占用非线性增长、栈深度激增，甚至静默生成错误副本（如部分字段丢失、引用错位）。
看对象图是否存在不可达但被重复访问的节点
循环引用本身不必然导致崩溃，但会让深拷贝函数在相同路径上多次处理同一个原始对象。可通过以下方式快速筛查：
- 在拷贝前对原对象做一次轻量级拓扑扫描：用 WeakMap 记录已访问对象地址，若某对象第二次被遍历时命中缓存，即存在潜在循环
- 不依赖 JSON.stringify —— 它抛出 “Converting circular structure to JSON” 是结果，不是诊断手段；该错误只在序列化阶段触发，无法定位具体哪两个属性构成闭环
- 对关键对象打印 Object.is(obj, obj.prop?.prop?.prop) 类型的自反检查，适用于已知可能存在自引用的简单结构（如树节点的 parent/children）
比对拷贝前后对象的引用关系一致性
真正的“原始一致性校验”，不是比值，而是比结构映射关系。例如：
- 设原对象 a.b = c，c.d = a，构成 a ↔ c 循环。理想深拷贝后应满足：cloneA.cloneB === cloneC 且 cloneC.cloneD === cloneA
- 若实际得到 cloneC.cloneD === undefined 或指向一个新对象而非 cloneA，则说明拷贝过程破坏了原始拓扑——常见于未用 cache 统一管理引用，或对特殊类型（如 Map、Set）未做映射还原
- 可用辅助函数做批量验证：checkCyclePreserved(original, cloned, path = [])，递归比对每条引用链的终点是否严格对应
监控拷贝过程中的缓存命中率与递归深度
高性能深拷贝实现中，WeakMap 缓存是防膨胀的第一道闸。观察它的行为能暴露问题：
- 若缓存 set 次数远小于 get 次数（比如 set 5 次，get 超过 50 次），说明大量对象被反复传入递归，极可能陷入循环
- 记录每次递归调用的深度，当出现连续多个调用深度 > 100 且对象类型相似（如全是 Object 或全是 Array），基本可判定为深层循环或失控嵌套
- 对大型对象，可在拷贝函数中插入采样日志：console.debug(`deepClone at ${path.join('.')}: ${obj.constructor.name}, cache size: ${cache.size}`)
用结构哈希替代全量比对做一致性快检
对复杂对象，逐字段比对引用太重。可构造轻量结构指纹：
- 为每个对象生成唯一标识符：基于构造函数名 + 属性键名集合 + 键值类型签名（如 "Object:[a:number,b:string,c:Date]"）
- 对原始对象图和拷贝后对象图分别构建“结构哈希树”，叶子节点为上述签名，父节点哈希 = hash(自身签名 + 子节点哈希排序串)
- 两棵树根哈希一致，说明拓扑结构未被破坏；不一致则说明循环处理逻辑出错（如某个循环边被跳过、某个 Date 被转成字符串未还原）
