如何实现Python类的深拷贝与浅拷贝_使用copy模块中的copy与deepcopy

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《如何实现Python类的深拷贝与浅拷贝_使用copy模块中的copy与deepcopy》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

浅拷贝 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() 会递归遍历所有嵌套对象，重建整棵树。它不是“更安全的浅拷贝”，而是有明确代价的操作。

常见性能陷阱：

• 类中含循环引用（如 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__ 可被意外污染。

真正麻烦的永远是那些看起来“应该没事”的嵌套字典或列表字段，以及没意识到自己持有了不可拷贝资源的类设计。

终于介绍完啦！小伙伴们，这篇关于《如何实现Python类的深拷贝与浅拷贝_使用copy模块中的copy与deepcopy》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！