深拷贝存在循环引用、不可序列化对象、自定义类适配及性能副作用四大风险。需检测哈希逻辑、实现__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__ 且未正确处理描述符，结果可能不是真正独立的副本，而是共享底层缓冲区。
立即学习“Python免费学习笔记（深入）”；
- 使用 NumPy 时优先调用
.copy()而非copy.deepcopy - 含
__slots__的类应显式在__deepcopy__中处理 slot 属性 - 对内存敏感场景（如图像处理、科学计算），用
id()或np.shares_memory()验证是否真隔离
性能与副作用隐患
deepcopy 是深度遍历操作，时间与空间开销都随嵌套层级和对象数量增长。更隐蔽的问题是：如果对象的 __init__、__new__ 或某些属性的 getter 触发了副作用（如写日志、发请求、修改全局状态），deepcopy 过程中可能意外执行这些逻辑。
- 避免在构造函数或属性访问中埋入副作用
- 对高开销或带副作用的对象，考虑用工厂函数替代 deepcopy
- 用
copy.copy+ 关键字段手动重建，往往比盲目 deep copy 更可控
深拷贝是强大工具，但不是银弹。理解它的工作边界，比记住“用 deepcopy 就安全”更重要。
