copy.copy() 对嵌套字典只做浅拷贝，新建字典但共享嵌套对象引用；cfg['db'] 与 cfg2['db'] 内存地址相同，修改 cfg2'db' 会同步影响 cfg；验证须逐层比对 id()，仅顶层地址不同不等于安全。
因为 copy.copy() 只复制字典本身，不递归复制它的值——只要值是可变对象（比如另一个字典、列表），新旧字典就仍共享这些嵌套对象的引用。
copy.copy() 对嵌套字典到底做了什么
它新建一个空字典，然后把原字典的键和“值的引用”逐个塞进去。如果某个值是 {'port': 5432} 这样的字典，copy.copy() 并不会为它再建一份副本，而是让新字典的对应键也指向同一块内存。
- 现象：
cfg = {'db': {'host': 'localhost'}}; cfg2 = copy.copy(cfg); cfg2['db']['host'] = '127.0.0.1'→cfg['db']['host']也变成'127.0.0.1' - 验证方式：
id(cfg['db']) == id(cfg2['db'])返回True - 适用场景：仅当字典所有值都是不可变类型（
str、int、tuple）时才安全；一旦含list、dict、set或自定义类实例，就无法隔离
为什么 dict.copy() 和 copy.copy() 行为不一致
dict.copy() 是字典类型自己的方法，只保证顶层字典独立，对嵌套结构不做任何特殊处理；copy.copy() 是通用接口，对所有类型统一按“浅拷贝语义”执行——二者在嵌套字典上效果完全相同，但容易误以为 dict.copy() 更“智能”。
-
cfg.copy()和copy.copy(cfg)在嵌套字典上表现一致，都只做一层复制 - 它们都不支持传参控制深度，也没有“跳过某些键”的选项
- 若你用的是
cfg2 = {**cfg}，结果也一样——仍是浅拷贝
什么时候必须换用 copy.deepcopy()
只要嵌套结构里存在任何可变对象，并且你后续会原地修改（比如 .update()、['key'] = val、.append()），就必须用 copy.deepcopy()，否则修改必然穿透到原始数据。
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
立即学习“Python免费学习笔记（深入）”；
- 典型高危场景：配置字典传给下游函数前临时覆盖某字段、测试中构造多组相似参数、缓存字典用于多次写入
- 注意边界：遇到循环引用（A 含 B，B 含 A）、文件句柄、
threading.Lock会直接抛RecursionError或TypeError - 性能提示：对纯数据结构（无自定义类、无外部资源），
json.loads(json.dumps(obj))有时更快，但不支持datetime、set、bytes等类型
最容易被忽略的验证步骤
别只检查 id(cfg) != id(cfg2) 就认为“拷贝成功”——必须逐层比对嵌套对象的 id()，尤其是你打算修改的那一层。
- 错误验证：
print(id(cfg), id(cfg2))→ 地址不同 ✅，就以为万事大吉 - 正确验证：
print(id(cfg['db']), id(cfg2['db']))→ 若相同 ❌，说明还是共享引用 - 更稳妥的做法：改完后反向检查原始对象是否被污染，而不是依赖“看起来像新对象”
真正麻烦的不是“不知道要用 deepcopy”，而是改完代码后没验证嵌套层级是否真的断开了引用——这一步漏掉，等于白拷贝。
