Python 中“深拷贝”一定安全吗？

深拷贝存在循环引用、不可序列化对象、自定义类适配及性能副作用四大风险。需检测哈希逻辑、实现__deepcopy__、避免对“活”资源调用，并警惕副作用与开销。

深拷贝并不总是安全的，它能解决大部分对象复制问题，但存在几个关键例外场景，容易引发意外行为甚至崩溃。

循环引用可能导致无限递归

当对象内部存在循环引用（比如 A 持有 B，B 又持有 A），copy.deepcopy 默认会检测并缓存已拷贝的对象，避免死循环。但这依赖于 Python 的递归限制和哈希/可变性判断——如果自定义类重写了 __hash__ 或 __eq__ 逻辑异常，或包含不可哈希的可变组件（如含列表的字典作为键），deepcopy 可能误判、跳过缓存，进而触发 RecursionError 或静默出错。

• 检查自定义类是否正确定义了 __hash__ 和 __eq__
• 对含复杂嵌套结构的对象，先用 sys.setrecursionlimit() 临时提高限制（慎用）
• 更稳妥的方式是手动实现 __deepcopy__ 方法，显式控制循环引用处理

不可序列化的对象无法深拷贝

文件对象、线程锁、数据库连接、socket、lambda 函数等“活”资源，本身不支持序列化，deepcopy 会直接抛出 TypeError。这不是 bug，而是设计使然：这些对象代表的是运行时状态，无法被复制。

• 遇到 TypeError: cannot pickle ... 时，说明对象含不可拷贝成分
• 可在类中实现 __deepcopy__，对特殊字段跳过拷贝或重新初始化（例如锁 → 新建 threading.Lock()）
• 必要时改用浅拷贝 + 手动重建关键部分，而非强求全量 deep copy

自定义类未适配时行为不可控

如果类没有定义 __deepcopy__，Python 会尝试按默认规则逐个拷贝其 __dict__

中的属性。但若属性是 C 扩展对象、内存视图（memoryview）、NumPy 数组（某些视图模式），或使用了 __slots__ 且未正确处理描述符，结果可能不是真正独立的副本，而是共享底层缓冲区。

• 使用 NumPy 时优先调用 .copy() 而非 copy.deepcopy
• 含 __slots__ 的类应显式在 __deepcopy__ 中处理 slot 属性
• 对内存敏感场景（如图像处理、科学计算），用 id() 或 np.shares_memory() 验证是否真隔离

性能与副作用隐患

deepcopy 是深度遍历操作，时间与空间开销都随嵌套层级和对象数量增长。更隐蔽的问题是：如果对象的 __init__、__new__ 或某些属性的 getter 触发了副作用（如写日志、发请求、修改全局状态），deepcopy 过程中可能意外执行这些逻辑。

• 避免在构造函数或属性访问中埋入副作用
• 对高开销或带副作用的对象，考虑用工厂函数替代 deepcopy
• 用 copy.copy + 关键字段手动重建，往往比盲目 deep copy 更可控

深拷贝是强大工具，但不是银弹。理解它的工作边界，比记住“用 deepcopy 就安全”更重要。