Python 复制嵌套列表后为什么原数据也被修改

你以为已经复制了列表，改副本里的数据后，原列表却跟着变化，最常见的原因不是 Python 把变量“串了”，而是只复制了最外层容器。对嵌套列表来说，list.copy()、切片和 copy.copy() 都是浅复制；要让内层可变对象也独立，通常应使用 copy.deepcopy()。

问题现场：浅复制只换了最外层列表

下面这个场景很容易出现在处理配置、表格行或接口返回数据时：先复制一份列表，再给副本中的某一行追加内容。

source = [["北京", 18], ["上海", 22]]
backup = source.copy()  # 只复制最外层列表
backup[0].append("晴")  # 内层列表仍可能与 source 共享

print(source)
# [['北京', 18, '晴'], ['上海', 22]]

backup 和 source 是两个不同的外层列表，但它们的第一个元素仍然指向同一个内层列表。Python 官方文档把这种行为称为 shallow copy：新建复合对象，再把原对象中的引用放进去。赋值语句则更直接，只是让两个名字绑定到同一个对象。

用 id 和等号检查到底共享了哪一层

排查时不要只打印内容，因为两个列表打印出来可能完全一样。用 is 判断身份，能直接确认两个表达式是否指向同一个对象；id() 则适合把各层关系记录下来。

source = [["北京", 18], ["上海", 22]]
shallow = source.copy()  # 外层产生新列表

print(source is shallow)       # False：外层不是同一个对象
print(source[0] is shallow[0]) # True：第一行仍是同一个内层列表
print(id(source[0]), id(shallow[0]))  # 两个 id 相同

可以把判断记成一张小清单：

这里的“通常共享”很重要：浅复制复制的是引用，不是无条件复制每一个元素。若元素本身是整数、字符串或元组等不可变对象，修改动作往往会产生新对象，看起来就不像共享问题；真正容易暴露问题的是列表、字典和集合。

用 copy.deepcopy 复制嵌套可变对象

当副本要独立编辑多层结构时，导入 copy 模块并使用 deepcopy：

from copy import deepcopy

source = [["北京", 18], ["上海", 22]]
editable = deepcopy(source)  # 递归复制嵌套对象
editable[0].append("晴")     # 只修改副本中的内层列表

print(source)   # [['北京', 18], ['上海', 22]]
print(editable) # [['北京', 18, '晴'], ['上海', 22]]
print(source[0] is editable[0])  # False

官方文档对两者的边界解释得很清楚：浅复制只把原对象里的引用放进新容器，深复制则递归地把其中对象也复制出来。deepcopy 内部还会用 memo 记录当前复制过程中已经处理过的对象，避免递归结构反复展开。

什么时候不该直接 deep copy

deepcopy 解决的是“副本不应共享嵌套对象”这个问题，不等于所有数据都应该完整复制。对象很大时，递归复制会增加时间和内存；如果某个缓存、只读配置或连接相关对象本来就应该共享，复制它反而会让语义变复杂。

工程上可以按修改边界选择方案：只改最外层就用浅复制；只需抽取字段就显式重建新列表或字典；确实要隔离多层列表、字典和集合时再用 deepcopy。自定义类还可能通过 __copy__() 或 __deepcopy__() 控制复制行为，遇到这类对象要先看它的实现约定。

常见问题

列表推导式能替代 deepcopy 吗？

只写一层列表推导式，例如 [row[:] for row in source]，可以明确复制每一行，但它只覆盖你写出的层级。嵌套更深或结构混合时，仍需逐层重建或使用 deepcopy。

为什么修改整数没有暴露浅复制问题？

整数是不可变对象，重新赋值不会在原整数上原地修改；列表和字典支持原地变更，所以共享引用更容易表现为“原数据也被改了”。

怎么判断是否真的需要深复制？

先列出副本允许修改的层级，再用 is 检查这些层是否共享。只要共享对象会被原地修改，就需要逐层重建或深复制；不修改的共享数据可以保留。

因此，看到“复制嵌套列表后原数据被修改”，先检查复制深度，不要急着给业务逻辑加额外锁或回滚。找出共享的那一层后，选择浅复制、显式重建或 deepcopy，问题通常就能稳定解决。