copy.deepcopy 在递归引用或极深嵌套结构中栈溢出，因其依赖深度优先递归遍历且无内置深度限制；可通过 memo 限深、迭代实现、pickle 替代或降级策略应对。
为什么 copy.deepcopy 在递归引用结构里会栈溢出
因为 copy.deepcopy 默认靠递归遍历对象图，遇到循环引用（比如 a.b = b 且 b.a = a）时，它依赖内部的 memo 字典缓存已访问对象来终止递归。但如果对象嵌套极深（比如链表有 10 万级节点，且每个节点只指向下一个），即使没循环引用，纯深度也会压爆 CPython 默认约 1000 层的递归限制。
这不是 bug，是设计使然：深度优先 + 无显式栈控制 + 无深度阈值保护。
- 典型报错：
RecursionError: maximum recursion depth exceeded while calling a Python object - 触发场景：解析自定义 AST、处理带父子双向指针的树、反序列化恶意构造的嵌套 JSON/YAML 对象
-
sys.setrecursionlimit()能缓解但不治本——改太大可能触发 C 栈溢出，且无法跨平台稳定生效
用 copy.deepcopy 的 memo 参数手动限深
虽然文档没明说，但 copy.deepcopy 接受可选的 memo 字典作为第三个参数，它本质是“已访问对象 ID → 复制后对象”的映射表。我们可以提前注入一个带深度计数的包装字典，在每次递归进入前检查当前调用栈深度。
关键不是替换 memo，而是拦截递归入口——最稳妥的方式是重写 __deepcopy__ 方法或封装一层代理逻辑。
立即学习“Python免费学习笔记（深入）”；
- 推荐做法：在调用前用
sys.getrecursionlimit()动态设安全上限（如 500），再用try/except RecursionError捕获并降级为浅拷贝或抛业务异常 - 不要直接 patch
sys.setrecursionlimit全局生效——会影响其他协程或信号处理器 - 示例降级逻辑：
try: result = copy.deepcopy(obj, memo={}) except RecursionError: raise ValueError("Object too deeply nested; deepcopy aborted")
改用迭代式深拷贝（绕过 Python 递归栈）
核心思路是把递归调用转成显式栈操作：用 list 或 collections.deque 存待处理节点，逐层展开字段，自己维护对象映射和循环引用检测。
这需要你清楚目标对象的结构（比如全是 dict/list/tuple/自定义类），不能像 copy.deepcopy 那样通用，但可控性强、无栈溢出风险。
- 对标准容器：遍历
obj.__dict__或vars(obj)，跳过__weakref__和描述符 - 对循环引用：用
id(obj)做键存入memo字典，后续遇到相同id直接返回已复制对象 - 性能权衡：比原生
deepcopy慢 2–5 倍，但内存更稳；适合已知结构的高可靠性场景（如配置加载、RPC 参数净化）
用 pickle 序列化+反序列化替代深拷贝
pickle.loads(pickle.dumps(obj)) 是公认的“深拷贝技巧”，因为它底层走的是 C 实现的序列化引擎，不依赖 Python 解释器递归调用栈，天然规避 RecursionError。
但它有硬性前提：对象必须可被 pickle（即实现 __reduce__ 或满足默认协议），且不能含不可序列化内容（如 lambda、打开的文件句柄、线程锁）。
- 安全用法：仅用于纯数据对象（
dataclass、NamedTuple、dict/list 嵌套） - 风险点：
pickle反序列化不受信任数据会执行任意代码，生产环境禁用 - 替代方案：若只需防栈溢出且对象简单，
json.loads(json.dumps(obj))更安全（但丢精度、不支持 tuple/set/自定义类）
真正难的不是选哪种方法，而是判断你的对象到底属于哪一类：是深度优先的长链，还是广度优先的稠密图，抑或混杂了不可序列化状态。没做结构分析就套方案，反而容易在边界 case 里翻车。
