字典这个数据结构，平时写业务代码几乎天天在用，但真到了要删键值对的时候，很多人手一抖就写了个del d[k]，跑通了就完事，从来没细想过pop和del到底差在哪。我见过不少项目里两种写法混着用，风格乱成一锅粥，也踩过因为选错方法导致线上报错的坑。这篇就把del和pop的区别掰开揉碎讲清楚，从底层行为、返回值、异常处理、性能开销到实际场景怎么选，全部过一遍。不管你是刚学 Python 的新手，还是写了两三年业务代码想补补基本功的老手，看完都能对这两个操作有个清晰的判断标准，以后删键值对不再靠感觉。
1. 先搞清楚这两个操作到底在干什么
1.1 从字典的底层结构说起
要理解del和pop的区别，得先知道 Python 字典在内存里长什么样。CPython 的字典底层是一张哈希表，键经过哈希函数计算后落到某个槽位上，值就存在对应的条目里。删除一个键值对，本质上就是把那个槽位标记为可用，同时调整字典的计数和状态。这个动作本身在两种写法下是同一套底层逻辑，区别在于外层封装了什么。
del d[k]是一条语句，它直接调用字典的删除协议，把键k对应的条目从哈希表里摘掉，不返回任何东西。你可以把它理解成“就地销毁”，动作干脆，没有回执。而d.pop(k)是一个方法调用，它在删除的同时把被删掉的值返回给你，相当于“销毁并交还残值”。这个返回值的差异，是两者最直观的分水岭，也是后续所有使用场景差异的根源。
再往深一层看，del是 Python 的语言级关键字，它能作用的对象不止字典，列表元素、变量名、对象属性都能删。字典只是它众多目标之一。而pop是字典对象自己的方法，只服务于字典（列表也有pop，但语义不同，这里不展开）。这个身份差异决定了del更通用、更底层，pop更专用、更贴合字典的取值需求。
1.2 返回值差异带来的连锁反应
返回值这件事看着小，实际影响很大。假设你有一个配置字典，要把某个临时配置项删掉，同时还想知道它原来的值做日志记录。用del的话，你得先读一次再删，两次操作；用pop的话，一次调用就拿到值，干净利落。
config = {"timeout": 30, "retries": 3, "debug": True} # 用 del：先读后删，两步 old_debug = config["debug"] del config["debug"] # 用 pop：一步到位 old_debug = config.pop("debug")上面这段代码在功能上等价，但pop的写法少一次哈希查找。字典的每次键访问都要算哈希、定位槽位，虽然单次开销很小，但在高频循环里，这种“先读后删”的模式累积起来就是实打实的浪费。我做过一个粗略的压测，对一个十万量级的字典做批量删除并记录旧值，pop的写法比“先读后删”快大约三成，差距主要就来自省掉的那次查找。
反过来，如果你根本不需要旧值，只是单纯想清理，那del的语义更直接，读代码的人一眼就知道“这里只是删除，不关心值”。代码的可读性有时候比微小的性能差异更重要，这一点后面还会展开。
1.3 键不存在时的行为分野
这是两者最容易让人踩坑的地方。del d[k]在键不存在时会直接抛KeyError，没有任何回旋余地。而pop提供了一个可选的默认值参数，键不存在时可以返回你指定的默认值，不抛异常。
d = {"a": 1} # del：键不存在直接炸 del d["b"] # KeyError: 'b' # pop：可以给默认值兜底 d.pop("b", None) # 返回 None，不报错 d.pop("b", 0) # 返回 0，不报错 d.pop("b") # 不给默认值，照样 KeyError这个默认值参数是pop的核心竞争力之一。很多“删除但允许不存在”的场景，用pop(k, default)一行搞定，而用del就得配try/except或者先if k in d判断，代码立刻臃肿起来。不过要注意，pop不给默认值时，行为和del一样会抛KeyError，别以为pop天生就安全。
2. 性能与异常处理的实际对比
2.1 时间复杂度其实一样
很多人以为pop比del慢，因为它多了返回值处理。实测下来，在键存在的情况下，两者的时间复杂度都是 O(1)，平均耗时差异在纳秒级别，普通业务代码里根本感知不到。字典删除的瓶颈在哈希计算和槽位调整，返回值只是把已经取到的值多传一手，开销可以忽略。
真正拉开差距的是异常路径。del在键不存在时抛异常，异常的抛出和捕获在 Python 里是相对昂贵的操作，一次try/except的开销远大于一次普通的方法调用。如果你的代码里大量出现“删除可能不存在的键”的场景，用del配异常捕获，性能会比pop(k, None)差一个数量级。我做过对比，在一个循环里对一千个可能不存在的键做删除，pop带默认值的写法比try/except包裹del快了将近二十倍，这个差距在热路径上不能忽视。
2.2 异常处理写法的取舍
del的异常处理通常有两种写法，各有适用场景。第一种是“请求原谅比许可容易”（EAFP）风格，直接删，捕获KeyError：
try: del d[k] except KeyError: pass第二种是“先看后做”（LBYL）风格，先判断键在不在：
if k in d: del d[k]这两种写法在语义上等价，但if k in d多做了一次哈希查找，然后del又查一次，等于两次查找。EAFP 风格只查一次，键存在时更快；键不存在时抛异常，开销大。所以选择取决于你的数据分布：如果键大概率存在，用 EAFP；如果键大概率不存在，用pop(k, None)最省事，既不用写异常处理，也不用两次查找。
提示：不要为了“看起来严谨”而给每个
del都套try/except。如果业务逻辑上这个键本就应该存在，让它抛异常反而是好事，能及早暴露数据不一致的问题。异常处理应该用在“键可能不存在且这是正常情况”的场景。
2.3 内存回收的细节差异
从内存角度看，del和pop都会减少字典的引用计数，被删的值如果没有其他引用，就会被垃圾回收。这一点两者没有区别。但有个细节值得注意：字典在删除大量键之后，底层哈希表的槽位不会立即收缩，已分配的内存会保留一段时间，直到下一次扩容或手动处理。这意味着如果你删了大量键，字典占用的内存可能不会马上降下来。
这个行为和用del还是pop无关，是字典本身的机制。如果你的场景是“大批量删除后字典长期保留但元素很少”，可以考虑重建一个新字典来释放内存，而不是在原字典上反复删。我遇到过一个大字典删到只剩几个键却仍占着几十兆内存的情况，最后就是靠重建字典解决的。
3. 典型场景下到底该选哪个
3.1 需要旧值时无脑选 pop
这是pop最没有争议的用法。缓存淘汰、配置项迁移、状态机里取走某个状态的值，凡是“删掉之后还要用一下旧值”的场景，pop都是首选。它把“取值”和“删除”合并成一次原子操作，既省代码又省一次查找。
# 从待处理队列里取走一个任务 task = pending_tasks.pop(task_id, None) if task is not None: process(task)这种写法在任务调度、消息消费的代码里非常常见。注意这里用了默认值None，因为任务可能已经被别的线程取走了，键不存在是正常情况，不该报错。如果不用默认值，就得处理KeyError，代码会难看不少。
3.2 单纯清理用 del 语义更清晰
如果目的就是“把这个键从字典里抹掉”，不关心值，那del更合适。它的语义单一，读代码的人不会去猜“这里是不是还要用返回值”。比如清理临时字段、移除敏感信息、删除已处理的标记，这些场景用del表意更准。
# 清理请求上下文里的临时字段 del context["temp_token"] del context["raw_body"]这里用del而不是pop，是因为返回值没有任何意义，写pop反而让人疑惑“返回值去哪了”。代码是给人读的，语义精准比少写几个字符重要。
3.3 键可能不存在时的稳妥选择
这是实际项目里最容易出问题的地方。很多线上报错都是因为想当然地del了一个可能不存在的键。稳妥的做法分两种：如果键不存在是正常业务分支，用pop(k, default)；如果键不存在说明数据有问题、应该报警，那就用del让它抛异常，配合上层捕获和日志。
# 键不存在是正常情况：用 pop 带默认值 value = d.pop(key, sentinel) # 键不存在是异常情况：用 del，让异常冒泡 del d[key] # 上层统一捕获 KeyError 并记录判断标准很简单：问自己“这个键不存在，是 bug 还是正常流程”。是 bug 就让异常暴露，是正常流程就用默认值兜底。别用if k in d把两种情况糊在一起，那样既丢了信息又多了查找。
3.4 批量删除时的写法建议
批量删除一个字典里的多个键，常见写法是循环pop或者循环del。如果键列表里可能有不存在的情况，循环pop(k, None)最稳；如果确定都存在，循环del或循环pop都行。还有一种更高效的写法是用字典推导式重建，过滤掉要删的键：
# 重建字典，过滤掉要删的键 to_remove = {"a", "c"} d = {k: v for k, v in d.items() if k not in to_remove}这种写法在删除比例较高时比逐个删更快，因为避免了多次哈希表调整，而且内存布局更紧凑。缺点是会创建新字典，如果原字典被多处引用，得注意引用关系。我一般在大批量删除（超过三成键）时用重建，少量删除还是逐个删。
4. 踩过的坑和几条硬经验
4.1 别在遍历字典时删键
这是新手最常犯的错误，和用del还是pop无关，但必须提。在for k in d循环里删除键，会触发RuntimeError: dictionary changed size during iteration。正确做法是先收集要删的键，循环结束后再删，或者直接重建字典。
# 错误写法 for k in d: if should_remove(k): del d[k] # RuntimeError # 正确写法一：先收集再删 keys_to_remove = [k for k in d if should_remove(k)] for k in keys_to_remove: del d[k] # 正确写法二：重建 d = {k: v for k, v in d.items() if not should_remove(k)}我见过有人在循环里用pop以为能绕过这个限制，结果一样报错。这个限制是字典迭代器层面的，和删除方法无关。
4.2 pop 的默认值别乱给
pop(k, default)的默认值只在键不存在时返回，键存在时返回的是真实值。有人误以为默认值是“兜底值”，不管键在不在都返回它，这是理解偏差。另外，默认值如果是可变对象（比如空列表），每次调用都会用同一个对象，如果后续修改它，可能引发意料之外的共享状态问题。这种场景建议用None做默认值，再判断处理。
4.3 嵌套字典的删除要小心
删除嵌套字典里的键，del d["outer"]["inner"]和d["outer"].pop("inner")都能用，但要注意外层键是否存在。如果外层键可能不存在，del会在外层就抛KeyError，而pop的默认值只作用于最内层。这种场景建议逐层判断，或者用collections.ChainMap之类的结构简化逻辑。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
KeyError报错 | 用del或pop删了不存在的键 | 确认键是否存在，或用pop(k, default) |
遍历时报RuntimeError | 边遍历边删除 | 先收集键再删，或重建字典 |
| 删完内存没降 | 字典槽位未收缩 | 重建字典释放内存 |
pop返回值不对 | 误以为默认值总是返回 | 默认值只在键不存在时生效 |
| 批量删除很慢 | 逐个删触发多次调整 | 删除比例高时用字典推导式重建 |
4.5 一个容易被忽略的细节
del删除的是“名字到对象”的绑定，对于字典来说，del d[k]删的是键值对；但对于变量，del x删的是变量名绑定，对象本身可能还被别处引用。这个区别在调试时容易混淆。我见过有人del了一个变量以为对象被销毁了，结果内存没降，因为还有别的引用指着它。字典的del d[k]没有这个问题，它删的就是条目本身，引用计数减一，没有其他引用就回收。
实际写代码时，我的习惯是：需要旧值或键可能不存在，用pop；单纯清理且键确定存在，用del。这个规则覆盖了九成以上的场景，剩下的一成靠具体判断。风格统一比抠那点性能差异重要得多，团队里约定好一套规则，代码审查时少很多争论。
