Python del 删除的是名字而非对象：引用计数与垃圾回收深度解析

先抛个结论吧：del 这个关键字在 Python 里删的从来都不是“对象”本身，而是“名字”和对象之间的那层绑定关系。很多人写了几年 Python，一遇到 del 就下意识觉得“这是把变量销毁了、内存立刻释放了”，这个理解害人不浅。早些年我在做爬虫批量抓取图片时，就是抱着这种错误认知，结果程序跑着跑着内存越占越多，排查半天才发现问题根本不在 del，而在于我用错了删除的粒度。

这篇文章不打算只列语法，而是想把 del 背后那套“名字绑定、引用计数、垃圾回收”的机制彻底讲透。会从底层原理逐步展开，再结合我这些年写 Python 的实际经历，把高频用法、冷门技巧、容易踩的坑以及内存释放的真实情况全部说清楚。无论你是刚学 Python 的新手，还是写了好几年代码的老手，我相信里面都有能让你“哦原来如此”的内容。

1. 先澄清一个多数人搞错的结论：del 删掉的是名字，不是对象

1.1 从名字绑定说起，对象从来不是“装在”变量里的

要理解 del，首先得改变一个直觉：Python 里变量并不是一个“盒子”，对象也不是装在盒子里的东西。更准确的说法是，Python 的变量只是一个“名字标签”，它贴在一个对象上。对象存活于内存中的某个地址，而名字只是让你能通过一个名称去访问那个地址上的东西。

我习惯用一个生活化的类比来解释：对象是一间酒店房间，变量是挂在房间门上的门牌号。a = [1, 2, 3] 这个操作，相当于在 201 房挂上“房间号 A”的牌子；b = a 并不是重新开了一间房，而是给同一间 201 房再挂了一块“房间号 B”的牌子。房间只有一个，但门牌号可以挂很多个。

当你执行 del a 时，你做的事情只是把“房间号 A”这块牌子摘下来。房间本身还在，201 房里住着的 [1, 2, 3] 这个对象还活着，因为还有一块“房间号 B”的牌子指着它。只有当真的一块牌子都不剩了，这个房间才会被酒店回收。

这个比喻解释了为什么很多情况下 del 之后对象并没有被销毁，因为它只是减少了引用计数，并非直接触发销毁动作。只有当引用计数归零的时候，对象才会进入真正的垃圾回收流程。

1.2 用代码验证：del 之后对象可能还活着

光说不练假把式，写个简单的例子感受一下：

python复制import sys

a = [1, 2, 3]
b = a
print(sys.getrefcount(a))  # 通常输出 3，因为 getrefcount 自身也引用了一次

del a
print(b)  # [1, 2, 3]，b 还在正常使用这个列表
print(sys.getrefcount(b))  # 引用计数少了一次，但因为还有 b，对象不回收

在这个例子里，del a 之后列表 [1, 2, 3] 依然健在，因为 b 仍然引用着它。你依然可以正常遍历、修改这个列表。这就直接否定了“del 会销毁对象”的说法。

再看一个更极端的例子：

python复制a = [1, 2, 3]
b = a
del a, b

这里 del a, b 是连续摘掉两块牌子。第二次删除之后，列表对象的引用计数归零，这个时候对象才会被垃圾回收。注意，回收动作是 Python 解释器在引用计数归零的瞬间自动触发的，而你用 del 只是把引用计数推进到了零而已。

1.3 为什么这个认知很重要？

搞清楚了“删名字”和“删对象”的区别，很多实际问题就迎刃而解。比如你写了一段代码：

python复制data = load_large_file()
result = process(data)
del data

你确实把 data 这个名字删掉了，但如果 process() 函数内部把 data 存到了某个全局缓存里，或者有另一个变量还保留着它的引用，那么这份大文件数据依然在内存里待着，del data 只是拆掉了一块牌子。想要真正释放内存，你需要找到所有还牵着它的“门牌号”，全拆掉才行。

这个认知在处理长生命周期应用、内存泄漏排查时，比任何花哨的优化都重要。

2. del 与垃圾回收、del 方法的三角关系

2.1 del 不会直接调用 del，这是最常见的误读

__del__ 是 Python 类里的一个特殊方法，不少人会把它类比成 C++ 的析构函数。很多人以为执行 del obj 就是在调用 obj.__del__()，这是一个流传极广的错误说法。实际情况是：del obj 把 obj 从当前作用域中移除，如果因此导致对象引用计数归零，那么对象会被销毁，销毁前会调用 __del__ 方法。

也就是说，__del__ 不是由 del 主动调用的，而是由“引用计数归零”这个事件触发的。del 只是有可能间接导致这个事件发生。

python复制class Demo:
    def __del__(self):
        print("Demo 对象被销毁了")

obj = Demo()
other = obj
del obj  # 没有输出，因为 other 还引用着对象
print("--- 分割线 ---")
del other  # 此时引用计数归零，打印 "Demo 对象被销毁了"

运行这段代码你会看到，第一次 del obj 时没有任何输出，直到 del other 才真正触发 __del__。这个例子已经把两者的关系展示得很清楚了：del 删除名字，__del__ 响应销毁。

2.2 循环引用与 gc 模块的兜底机制

还有一种更隐蔽的情况，对象之间相互引用，即使外部名字全部删除，引用计数也永远不会归零。比如：

python复制class Node:
    def __init__(self, name):
        self.name = name
        self.partner = None

a = Node("A")
b = Node("B")
a.partner = b
b.partner = a

del a, b

执行完 del a, b 之后，两个 Node 对象还在通过 partner 属性相互引用着对方，引用计数都不是零。如果程序只依赖引用计数机制，这两个对象就是死循环里无人回收的垃圾。这时候就需要 Python 的 gc 模块出马了。

gc 模块会定期扫描所有的容器对象，寻找那些“循环引用且没有外部可达引用”的对象组，并把它们回收。所以理论上即使你写了上面的代码，gc 也会在某个时间点把它们清理掉。但 gc 的检测是有成本、有周期的，如果你写的是内存敏感的代码，循环引用还期望立即释放内存，那最好手动触发一下：

python复制import gc
gc.collect()

不过更规范的做法是从一开始就避免写出循环引用的结构。现代 Python 里可以用 weakref 来打破循环引用，某些场景下用 weakref.ref 或 weakref.WeakValueDictionary 就能无痛解耦。

2.3 实操建议：不要在 del 里做重要的事情

既然 __del__ 不一定被立即调用，甚至有可能因为循环引用而延迟到 gc 介入才调用，那么把资源释放逻辑放在里面就是不靠谱的。我见过不少初学者会在 __del__ 里写关闭文件、关闭数据库连接、发送网络请求之类的重要逻辑，结果程序退出时这些逻辑没执行或者执行时机完全不可控，导致数据丢失或文件句柄泄漏。

要释放资源，Python 更推荐使用 with 语句配合上下文管理器：

python复制with open("data.txt", "r") as f:
    content = f.read()

文件会在 with 块结束后自动关闭，即使中途抛异常也会走清理逻辑。数据库连接、锁对象等资源同理。__del__ 更适合做“日志输出”这一类不痛不痒的兜底事情，而不是核心资源管理。

3. del 在日常开发里的高频用法拆解

3.1 列表、字典中删除元素：del item 和 pop 怎么选

在列表里，del 最常见的用法是按索引切掉元素：

python复制lst = [10, 20, 30, 40]
del lst[1]  # [10, 30, 40]

del lst[1] 执行后，列表会自行收缩大小，后面的元素往前移动。这里有个性能细节值得留意：del lst[0] 这种从头部删除的操作，在长列表上是 O(n) 的，因为涉及所有元素整体移位。如果你要频繁地从头部或中部删元素，更合适的数据结构是 collections.deque，它专门优化了双端增删。

字典里删除键也是高频操作：

python复制d = {"name": "张三", "age": 18, "city": "上海"}
del d["age"]

del d[key] 不返回被删的值。如果你同时需要根据 key 删元素，又要拿到被删的那个 value，就该用 pop：

python复制d = {"name": "张三", "age": 18, "city": "上海"}
value = d.pop("age")  # value = 18

另一个容易搞混的是，del 删除不存在的 key 会抛 KeyError，而 pop 可以传默认值避免异常：

python复制d.pop("age", None)  # key 不存在时返回 None，不抛异常

所以我的经验是：如果你只想删、不关心返回值，且确定 key 一定存在，用 del；如果需要返回值，或者不确定 key 是否存在希望静默处理，用 pop。

3.2 切片删除：del lst[1:3] 的语义与清空列表的正确姿势

del 配合切片可以一次性删除一段连续元素，这个能力经常被忽略：

python复制lst = [1, 2, 3, 4, 5, 6]
del lst[1:4]  # 删除索引 1 到 3 的元素，结果 [1, 5, 6]

更妙的是，del lst[:] 能清空整个列表，但保留列表对象本身的内存地址。这和 lst = [] 有本质区别：

python复制original_id = id(lst)
lst[:] = []  # 或 del lst[:]
print(id(lst) == original_id)  # True，还是原来那个列表

那这个特性有什么用？如果你把列表传给了别的对象，别人保存着这个列表的引用。此时如果执行 lst = []，你只是把 lst 这个名字指向了新的空列表，原来的列表还是被那个对象引用着，数据根本没清掉；而执行 del lst[:] 或在原列表上做切片赋值 lst[:] = []，是在原地清空列表，另一个持有引用的人看到的就是一个空列表。

这个技巧在做缓存清理、共享状态重置时非常管用。我就曾经在处理一个全局配置表时，因为用了 config = {} 而不是 config.clear()，导致其他模块拿到的依然是旧配置，排查了比预期更久的时间。

3.3 删除对象属性和类属性：delattr 与 delitem 的联动

del 不仅能删变量、删列表元素、删字典键，还能删对象的属性：

python复制class User:
    def __init__(self, name, age):
        self.name = name
        self.age = age

user = User("张三", 18)
del user.age  # 删除实例属性 age
hasattr(user, "age")  # False

执行 del user.age 时，Python 实际上会调用 type(user).__delattr__(user, "age") 这个方法。如果你在类里自定义了 __delattr__，就可以拦截属性删除事件，做额外清理。

python复制class User:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def __delattr__(self, name):
        print(f"正在删除属性 {name}")
        super().__delattr__(name)

有一个很值得注意的坑：在 __delattr__ 里不要直接写 del self.name。因为 del self.name 会再次调用 __delattr__，然后再次进入这个方法，于是无限递归直到 RecursionError。要绕开，必须调用父类的 super().__delattr__(name) 或者 object.__delattr__(self, name)。

类似地，自定义容器类可以使用 __delitem__ 来响应 del obj[key]：

python复制class MyList:
    def __init__(self):
        self.items = []

    def __delitem__(self, index):
        print(f"删除索引 {index}")
        del self.items[index]

可以说，del 不只是一个语法糖，它还构成了 Python 数据模型的一部分。通过覆写 __delattr__ 和 __delitem__，你可以在删除行为上挂接自己的逻辑，实现类似“删除时自动清理关联资源”的效果。

3.4 del 与模块命名空间清理

del 还可以用来“卸载”模块里的导入项：

python复制import os
import sys

# 用完之后不想要 os 这个名字了
del os

这种操作在常规业务代码里用得不多，但有两个场景比较实用。一个是交互式编程环境，比如 Jupyter Notebook 里，你可能导入了一堆不再需要的模块，又不想重启内核，就可以用 del sys.modules["xxx"] 配合重新导入来模拟模块重载效果。另一个是当你写一些内存敏感的长驻服务时，临时 import 了一个大模块，用完之后可以 del 掉名字，让这个模块占用的引用得到释放。

不过要说明的是，del os 只是把当前作用域里的 os 名字移除，模块对象本身还存在于 sys.modules 中。再次 import os 时，Python 不会真正重新加载模块文件，而是直接从 sys.modules 里取缓存。如果你是真的想彻底卸载一个模块并强制重新加载，需要同时处理 sys.modules 里的条目。这个操作比较底层，一般场景不建议用。

4. 容易踩坑的边界场景与排查经验

4.1 for 循环变量残留问题

一个非常经典的坑是，Python 的 for 循环并不会像某些语言那样创建独立作用域。循环结束后，循环变量依然存在，而且保留的是最后一次遍历的值：

python复制for i in range(5):
    pass
print(i)  # 4，i 并没有消失

这往往会导致一些隐蔽的问题。比如你在循环里用了一个变量名 i，循环之后又在别的逻辑里定义了同名的 i，就很容易覆盖。如果不想让循环变量继续存在，可以在用完后 del i 来手动清理。

在推导式里情况有些特殊。Python 3 中，列表推导式里的循环变量有自己的作用域，不会泄漏到外面：

python复制squares = [x * x for x in range(5)]
print(x)  # NameError，x 不存在

但要注意，这是 Python 3 的行为，Python 2 里列表推导式是会泄漏循环变量的。如果你在维护老代码库，需要小心这一点。

4.2 闭包内使用 del 的坑

闭包（closure）是 Python 中很常见的机制。当你在闭包内引用外层函数的变量时，那个变量会存储在函数的 __closure__ 单元格里。如果你在外层函数中 del 了这个变量，闭包再访问它时会直接抛 NameError：

python复制def outer():
    x = 10
    def inner():
        return x
    del x  # 删除了自由变量的值
    return inner

inner = outer()
print(inner())  # NameError: free variable 'x' referenced before assignment in enclosing scope

这里的 del x 删除的是闭包单元格里保存的 x 的绑定值。之后 inner() 再去读取 x 时就找不到值了。这种行为在一个复杂项目里可能会因为某个人在外层函数里写了 del 而突然把内层函数搞挂，排查起来非常痛苦。

我的建议是：在涉及闭包的代码里，尽量不要对外层函数变量使用 del。如果真的需要释放某个大对象，更稳妥的做法是把变量重新赋值成 None：

python复制def outer():
    data = []
    def inner():
        return data
    # 不要 del data，而是：
    data = None

虽然 data = None 也会影响闭包读取到的值是 None，但至少不会产生 NameError 这种运行时异常，行为更可预测。

4.3 释放大数组时，内存占用看起来没下降

这是我在写数据处理脚本时最常遇到的一个困惑。下面这种写法在很多人看来应该是“删掉数组、释放内存”：

python复制import numpy as np
import gc

arr = np.random.rand(10000, 10000)  # 约 800MB
del arr
gc.collect()

但实际操作起来你会发现，del arr 之后进程的内存占用可能并没有立刻下降多少。原因有两层：

第一，del arr 只是把变量名从当前作用域移除。如果这个 numpy 数组还被其他变量引用，或者被某些计算表达式间接持有，那么它根本不会被释放。你需要保证所有引用都解除。

第二，即使引用计数归零了，Python 的内存分配器也不会马上把内存返还给操作系统。Python 有自己的一套内存管理机制，会缓存一部分空闲内存以供后续复用。这是为了性能考量，因为频繁向操作系统申请内存是很贵的。

这种情况下，如果你想确认数组是否真的被回收，可以用 weakref 或者 gc.get_objects() 来检查：

python复制import gc
import numpy as np
import weakref

arr = np.random.rand(1000, 1000)
ref = weakref.ref(arr)
del arr
gc.collect()
print(ref())  # None，说明对象确实被回收了

如果 ref() 返回 None，说明对象确实已经销毁，只是内存没有还给操作系统。这时候一般不用过度担心，因为 Python 会把内存留给自己内部复用。真正需要担心的是引用没断干净的情况。

4.4 交互式环境中的 _ 下划线问题

交互式环境里有个隐藏变量 _，它会自动保存上一次执行的表达式结果。这个特性和 del 结合起来会产生很奇怪的 bug。比如你在 Jupyter Notebook 里跑：

python复制import pandas as pd
df = pd.read_csv("large.csv")

此时 _ 可能就指向了 df。如果你执行 del df，本来以为 DataFrame 已经释放了，但 _ 仍然握着这个对象的引用，内存一点没少。当你再执行其他表达式时，_ 才会被覆盖。

所以在交互式环境里排查内存问题时，需要留意 _ 变量。想彻底释放，有时候得这样：

python复制del df, _

这个细节极其容易被忽略，因为 _ 是隐式存在的。

5. del 的底层设计哲学与我的使用规范

5.1 del 与 C++ delete 的本质差异

很多从 C++ 转 Python 的朋友对 del 有天然的不适应，因为它和 C++ 的 delete 关键字虽然名字相似，语义却大不相同。C++ 的 delete 会立即释放内存、调用析构函数，是程序员手动管理内存的一种手段。而 Python 的 del 更像是一种“告知解释器我暂时不再需要这个引用了”的声明，实际的对象生命周期完全由引用计数和垃圾回收器统一管理。

这种差异背后反映了两种语言的设计哲学。C++ 倾向于精确控制、零抽象开销，希望程序员对内存有完全掌控。Python 则选择让开发者专注于业务逻辑，把内存的收尾工作交给解释器。用一个不太严谨但实用的说法：C++ 的 delete 是手动销毁，Python 的 del 是“撤退”。

理解了这层差异，你就不会对 del 抱有不切实际的期待了。它只是帮你提前释放引用，让对象可以在不需要时尽快被回收，而不是一个内存释放开关。

5.2 我个人的使用经验：什么时候该用、什么时候不该用

在实际开发中，我对 del 的使用遵循几条原则：

第一，在长循环或长生命周期的代码里，如果确实有某个大对象不再需要了，del 是个好习惯。比如每个迭代都会创建一个超大的临时列表，用完之后及时 del，配合 gc 的自动回收，可以显著缓解内存峰值。

第二，如果只是想断开一个名字引用，且不关心底层对象的生与死，用 del 很合适。但要记住，它只是“撕标签”，不是“拆房子”。

第三，资源释放（文件、锁、网络连接、数据库会话）优先用 with 语句，不要依赖 del 或 __del__。这不是说不能用，而是不可控、不推荐。

第四，如果发现自己需要在代码里频繁写 del 才能维持内存稳定，那么很可能问题出在设计上。比如你在循环里反复创建大对象，有可能是数据没复用，或者引用的生命周期比你预期的要长。不要用 del 去掩盖设计缺陷，先找根因。

最后分享一个小技巧：查看一个对象当前有哪些引用，可以用 gc.get_referrers(obj)。当你不知道为什么 del 之后对象还活着时，这个函数能把所有“隐藏的持有者”揪出来，是排查 Python 内存泄漏的实战利器。

python复制import gc

obj = []
holder = [obj]
print(gc.get_referrers(obj))

这个函数我无数次用它找到了藏在全局变量、异常栈、闭包单元格里的意外引用。Python 的内存管理有时候就像一座迷宫，del 只是你手里的地图，真正决定敌人（内存泄漏）会不会出现的，是迷宫本身的结构。把底层的引用关系理清了，del 用起来自然得心应手。