浅拷贝 copy.copy() 在对象含可变嵌套对象（如 list、dict）且被原地修改时出问题，导致新旧对象共享同一内存；深拷贝开销在于递归遍历、处理循环引用及不可序列化对象；自定义类需重写 deepcopy 控制资源字段；浅拷贝适用于仅含不可变字段或能确保不触发共享副作用的场景。
浅拷贝 copy.copy() 什么时候会出问题
浅拷贝只复制对象本身，不递归复制其内部的可变对象。当你对原对象里的列表、字典、自定义类实例等做修改时，拷贝体也会跟着变——这是最常被忽略的“副作用”。
典型场景：类中包含 list 或 dict 类型的属性，且后续会原地修改（如 .append()、['key'] = value）。
- 使用
copy.copy()后，新旧实例的self.data指向同一份内存 - 修改
obj1.data.append(1)，obj2.data也多出一个元素 - 对不可变类型（
int、str、tuple）无影响，因为它们无法原地修改
深拷贝 copy.deepcopy() 的真实开销在哪
copy.deepcopy() 会递归遍历所有嵌套对象，重建整棵树。它不是“更安全的浅拷贝”，而是有明确代价的操作。
常见性能陷阱：
立即学习“Python免费学习笔记（深入）”；
- 类中含循环引用（如 A 持有 B，B 又持有 A）——
deepcopy能处理，但需额外哈希表记录已拷贝对象，带来内存与时间开销 - 含有文件句柄、线程锁、数据库连接等不可序列化对象时，会直接抛
TypeError: cannot pickle ... - 自定义类未实现
__reduce__或__getstate__，但内部字段含不可拷贝对象，也会失败
示例错误：TypeError: cannot pickle _thread.RLock objects —— 这说明你试图深拷一个带锁的实例。
自定义类要支持深拷贝，必须注意什么
默认情况下 deepcopy 能处理大多数情况，但一旦类里有资源型字段（如打开的文件、socket、C 扩展对象），就必须手动干预。
- 重写
__deepcopy__(self, memo)方法，在里面控制哪些字段跳过、哪些用copy.deepcopy(x, memo)显式处理 -
memo是个字典，用于缓存已拷贝对象，防止循环引用无限递归；调用子对象深拷贝时务必传入它 - 如果某字段不该被拷贝（比如日志器
self.logger），在__deepcopy__中直接赋值原对象或重新获取
简单示意：
def __deepcopy__(self, memo):
new_obj = MyClass.__new__(MyClass)
memo[id(self)] = new_obj
new_obj.name = copy.deepcopy(self.name, memo) # 深拷字符串没问题
new_obj.cache = {} # 不拷贝缓存，新建空字典
new_obj.logger = self.logger # 复用原 logger 实例
return new_obj
什么时候该用浅拷贝，而不是无脑上 deepcopy
不是所有拷贝都需要“彻底隔离”。浅拷贝在以下情况更合理、更高效：
- 类实例只含不可变字段（
int、str、tuple），或你明确知道不会修改嵌套可变对象 - 拷贝后立即要重置内部状态（如
obj.reset()），那深拷贝的“干净初始态”并无意义 - 性能敏感路径（如高频创建中间对象），且能确保后续不触发共享引用的副作用
一个反直觉但实用的点：如果你的类实现了 __slots__，且不含可变容器字段，copy.copy() 的行为其实和你预期的“安全拷贝”几乎一致——因为没有 __dict__ 可被意外污染。
真正麻烦的永远是那些看起来“应该没事”的嵌套字典或列表字段，以及没意识到自己持有了不可拷贝资源的类设计。
