deepcopy 遇循环引用会抛 recursionerror，因其依赖递归遍历且 memo 缓存无法终止闭环路径；解决需重构为无环结构、自定义 __getstate__ 跳过循环字段，或手动拓扑拷贝。
处理含循环依赖的图结构数据模型时，直接调用 copy.deepcopy() 会立即抛出 RecursionError。这不是代码写错了，而是 Python 深拷贝机制在遇到“对象 A → B → A”这类闭环引用时，无法终止递归遍历，最终触发最大递归深度限制。
为什么循环依赖会让 deepcopy 失效
deepcopy 内部维护一个已访问对象的缓存（memo），用于避免重复拷贝同一对象。但它的设计前提是：所有引用路径最终都能抵达“叶子节点”（如数字、字符串）或无环终点。一旦出现循环引用（例如父节点保存子节点引用，子节点又反向持父节点引用），deepcopy 就会在缓存中反复查找、记录、再进入——陷入无限递归。
典型报错示例：
a = {}
a['self'] = a
copy.deepcopy(a) # RecursionError: maximum recursion depth exceeded
绕过循环依赖的三种可行路径
不强行深拷贝，而是从数据建模和拷贝策略上做调整：
-
拆解引用关系，改用 ID 或路径标识：把双向引用改为单向 + 标识符。例如，子节点不再直接存
parent_obj，而是存parent_id；拷贝时只复制 ID，后续按需查表重建关联。这样结构变为有向无环图（DAG），deepcopy 可安全执行。 -
自定义
__reduce__或__getstate__：在类中显式控制序列化行为。跳过循环字段，或将其替换为占位值。例如：
state = self.__dict__.copy()
state.pop('parent', None) # 移除导致循环的属性
return state
- 手动实现拓扑拷贝：先用 DFS/BFS 遍历图，生成节点顺序列表；再按顺序逐个创建新对象（仅初始化字段，暂不设引用）；最后第二轮填充引用关系。整个过程避开递归，完全可控。
哪些情况其实根本不需要深拷贝
很多场景下，所谓“必须深拷贝”，其实是设计惯性带来的错觉：
- 如果图结构只用于只读计算（如图算法推理、配置校验），可直接共享引用，配合
copy.copy()做顶层隔离即可； - 若需临时修改并回滚，可用上下文管理器记录变更 diff，比全量拷贝更轻量；
- 在持久化或跨进程传递时，序列化（JSON/pickle）天然打破内存引用，此时应优先走序列化-反序列化流程，而非内存内 deep copy。
小结：关键不在“怎么拷”，而在“为何要拷”
面对循环依赖图，硬刚 deepcopy 往往是下策。优先检查是否能重构为无环结构、是否可延迟/按需建立引用、是否混淆了“逻辑副本”与“内存副本”的需求。真正需要完整内存隔离的场景并不多，多数时候，清晰的数据契约比盲目的拷贝更可靠。
