copy.deepcopy在嵌套列表上特别慢是因为它必须逐层判断类型、检测循环引用、缓存对象，全是Python层开销；而规整二维列表应优先用列表推导式或np.array().copy()。
copy.deepcopy 为什么在嵌套列表上特别慢
它不假设你的数据结构是规整的：哪怕你心里清楚这是个 1000×1000 的纯整数二维表，copy.deepcopy 还是得对每个 [] 判断是不是 list、要不要递归、有没有循环引用、要不要缓存……这些操作全是 Python 层的堆分配和函数调用，没有内存连续性，也没有批量复制能力。
常见错误现象：copy.deepcopy(nested) 在处理千级二维列表时耗时常超 300ms，而同等 np.array().copy() 仅需 3–5ms；内存占用高 2–3 倍，且 CPU 缓存不友好——每个子列表地址不连续，导致频繁 cache miss。
二维/规整嵌套列表优先用列表推导式
如果你的数据是“所有子列表等长、元素类型一致”的二维结构（比如表格、图像像素、坐标矩阵），根本不需要递归。
- 替代
copy.deepcopy(nested)：写成[row[:] for row in nested] - 若需三维（固定深度为 3）：用
[[x for x in row] for row in nested]，比deepcopy快 2–5 倍，内存低 2 倍以上 - 注意：这种写法不处理循环引用，但绝大多数业务数据本来就没有
能转 NumPy 就别硬扛纯 Python
只要嵌套结构是矩形的（每行长度一致）、元素类型统一（如全 int/float），np.array(data).copy() 是最省心的加速路径。
立即学习“Python免费学习笔记（深入）”；
- 实测：1000×1000 整数二维表，
np.array().copy()耗时稳定在3–5ms，deepcopy波动在300–500ms - 陷阱：
arr.tolist()会重新触发深拷贝开销，所以尽量全程用数组操作 - 警告：含
None、混合类型（如[1, "a"]）、不等长子列表，会退化为dtype=object，失去性能优势
多数场景其实压根不需要 deepcopy
很多人把 copy.deepcopy 当成“防出错开关”无脑开，但多数业务场景根本没那么脆弱。
- 只读副本？直接传原对象，或加注释说明“禁止修改嵌套项”
- 只改顶层（比如替换某一行：
new_data[5] = [9, 8, 7]）？new_data = old_data.copy()足够 - 只有一两处嵌套需要隔离（比如只改
config["users"][0]["tags"]）？手动复制那条路径：config_copy = copy.copy(config); config_copy["users"] = config["users"].copy() - 原始数据本身不含可变嵌套（例如全是
int、str、tuple），copy.copy和deepcopy行为一致，但前者快一个数量级
真正容易被忽略的是：deepcopy 的代价不是“写法不对”，而是它本就不该出现在规整结构、单层变更、只读传递这些高频场景里。越早识别出实际变异边界，越能避开这个隐形性能陷阱。
