del 是从命名空间移除绑定的语句，仅减少引用计数，不直接释放内存；对象是否回收取决于引用计数是否降为0及cpython的内存管理机制。
del 是语句，不是函数，也不操作内存
Python 的 del 本质是「从命名空间中移除绑定」，比如执行 del x，Python 做的只是把名字 x 从当前作用域的符号表里删掉。它不碰对象、不调用 free()、不触发任何底层内存释放逻辑。
真正决定内存是否回收的是引用计数——每个对象内部有个 ob_refcnt 字段。只有当这个数降到 0，CPython 才会立即调用 tp_dealloc 清理对象并归还内存。
-
del只会让引用计数 −1，仅此而已 - 如果对象还被其他变量、容器、闭包、traceback 或 weakref 持有，
del后它依然活着 - 对小整数（如
3）、短字符串等常量对象，即使引用计数为 0，CPython 也可能缓存它们供复用，不真正释放
为什么不能像 C++ delete 那样直接释放？
因为 Python 是基于引用计数 + 周期性 GC 的自动内存管理语言，设计哲学就是「解耦命名与存储」。变量名只是标签，对象才是实体；标签可以贴多个地方，删一个不影响其他。
这种机制支撑了大量关键特性：
- 函数返回列表时，不用手动
malloc/free，调用方和实现方共享同一块内存 -
a = [1,2,3]; b = a后，del a不影响b访问数据 - 闭包捕获外部变量、异常 traceback 保留局部对象，都依赖「引用存在即对象存活」这一保证
常见误判：del 后内存没变小，是不是没生效？
不是。你看到 sys.getsizeof() 不变，或 psutil.Process().memory_info().rss 没下降，不代表 del 失效。原因包括：
- CPython 的内存分配器（如 pymalloc）会把刚释放的小块内存保留在池中，供后续同尺寸对象快速复用
- 操作系统通常不会立刻把内存还给系统，而是标记为“可重用”，RSS 数值滞后
- 对象本身可能还在被隐式引用，比如你刚抛过异常，
sys.exc_info()还持有栈帧里的变量
验证是否真被回收，更可靠的方式是检查引用计数：sys.getrefcount(obj)（注意该函数调用本身会 +1），或观察对象的 __del__ 是否被触发（仅适用于自定义类且无循环引用）。
del 列表元素时索引错位、删字典键失败，都是引用逻辑惹的祸
这些不是 bug，而是「删除引用」在不同容器中的自然表现：
-
del my_list[0]：删的是索引位置上的引用，后续元素前移，原my_list[1]变成my_list[0]—— 这是列表结构决定的，和引用无关但容易踩坑 -
del my_dict['missing']：直接抛KeyError，因为字典里根本没这个键的绑定，不存在「解除引用」这回事 -
del obj.attr：实际调用obj.__delattr__('attr')，能否删取决于类是否允许（比如@property未定义deleter就会报AttributeError）
所有这些行为，根源都在一点：Python 从不让你直接碰内存，它只管「谁还连着这个对象」。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
