python的copy.deepcopy()通过memo缓存、迭代模拟和不可变对象跳过三种机制安全处理深嵌套，无需手动递归；仅在极端场景才需分块、手动深拷或序列化替代。
深拷贝遇到过深嵌套对象时，核心问题不是“递归太深报错”，而是栈溢出风险和性能急剧下降。Python 的 copy.deepcopy() 默认已内置防护机制，并非简单粗暴递归到底。
deepcopy 自动应对深层嵌套的三种方式
它不靠无限递归，而是用更稳健的策略：
- 循环引用检测与缓存：内部维护一个 memo 字典，记录已复制过的对象 ID。一旦发现正在复制的对象已在 memo 中，就直接复用已有副本，避免重复递归甚至死循环
- 迭代替代递归：实际实现中大量使用栈（list）模拟递归过程，而非依赖 Python 解释器的函数调用栈，显著降低栈溢出概率
- 不可变对象跳过复制：遇到纯不可变结构（如只含 int/str/tuple 的嵌套），直接复用原对象，不递归也不分配新内存——这是安全且高效的优化
你不需要手动写递归函数
自己实现深拷贝递归极易出错，比如漏处理循环引用、忽略自定义类的 __getstate__ 或资源句柄。标准库的 copy.deepcopy() 已覆盖绝大多数场景，包括：
- 含 self 引用的类实例（如树节点父子互指）
- 带文件句柄、socket 连接等不可序列化资源的对象（此时会抛出
TypeError，提示你需重写__deepcopy__） - 超深但无环的嵌套（如 1000 层字典套字典），只要内存够，它就能完成
真遇到“太深”怎么办？先确认是不是真问题
所谓“过深”，往往不是层数本身，而是：
- 单个对象体积巨大（比如含百万级元素的嵌套列表）→ 耗的是内存和时间，不是栈深度
- 存在未察觉的循环引用 →
deepcopy会正常处理，但若自定义类没正确实现__deepcopy__，可能卡住或出错 - 误判：用
sys.getrecursionlimit()查到默认值是 1000，但deepcopy不走这个限制路径
极少数需要干预的场景
如果确实因结构极端复杂导致耗时过长或内存爆满，可考虑：
- 分块处理：把大对象拆成几个子结构，分别 deepcopy 再合并
- 浅层 + 手动深复制关键字段：对大部分只读字段用浅拷贝，仅对明确可变的嵌套部分单独 deepcopy
- 改用序列化方案：如
pickle.loads(pickle.dumps(obj))（注意安全性），某些情况下比 deepcopy 更快，但不支持所有类型
