__del__不能保证被调用，不可用于关键资源释放；应优先使用with语句（__enter__/__exit__）、显式.close()或weakref.finalize。
Python里__del__不是可靠的销毁钩子
直接说结论：__del__函数**不能保证被调用**，也不该用来释放关键资源（比如文件句柄、网络连接、数据库事务）。它只是CPython在对象引用计数归零且无循环引用时，*可能*触发的一个回调，但行为受解释器实现和运行时状态影响极大。
常见错误现象包括：__del__没执行、执行顺序不可控、甚至在解释器关闭阶段才被调用（此时模块已卸载，print或日志可能失效）。
- CPython中，若对象参与循环引用，
__del__可能永远不触发，直到垃圾回收器（GC）介入——而GC的时机不确定 - PyPy、Jython等解释器对
__del__的支持更弱，部分完全不调用 - 如果
__del__抛出异常，CPython会静默忽略，不报错也不传播
真正可控的资源清理：用with语句 + __enter__/__exit__
需要确保某段逻辑结束后立刻释放资源？别依赖__del__，改用上下文管理协议。这是Python官方推荐、跨解释器稳定、可预测的方案。
示例：一个封装文件读取的类
立即学习“Python免费学习笔记（深入）”；
class DataReader:
def __init__(self, path):
self.path = path
self.file = None
<pre class="brush:php;toolbar:false;">def __enter__(self):
self.file = open(self.path, 'r')
return self
def __exit__(self, exc_type, exc_val, exc_tb):
if self.file and not self.file.closed:
self.file.close() # 这里一定执行使用
with DataReader('data.txt') as dr: print(dr.file.read())
离开with块后，exit立即调用，文件必然关闭
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
__exit__会在with块退出时无条件执行，无论是否发生异常 - 比
try/finally更简洁，且天然支持多资源嵌套 - 若必须手动清理，优先调用显式方法（如
.close()），而非等待__del__
想监控对象生命周期？别靠__del__，用weakref.finalize
如果只是想“在对象被销毁时做点事”（比如打日志、统计内存占用），weakref.finalize比__del__更可靠、更安全。
它不绑定到实例，不阻止垃圾回收，且能明确指定回调函数和参数：
import weakref
<p>class CacheItem:
def <strong>init</strong>(self, key):
self.key = key</p><p>def on_cache_item_deleted(key):
print(f'CacheItem for {key} is gone')</p><p>item = CacheItem('user_123')
weakref.finalize(item, on_cache_item_deleted, item.key)
del item # 此时finalize回调大概率被触发（具体时机仍由GC决定，但不会失败）
-
finalize对象本身是弱引用，不影响目标对象生命周期 - 回调函数在对象真正被回收时执行，不依赖
__del__实现 - 支持注册多个finalize，互不干扰；也可主动调用
.cancel()取消
GC循环引用问题：用gc.collect()或避免强引用
当类中存在self.parent = parent这类反向引用，又没手动断开，就容易形成循环引用——这时__del__彻底失效，连CPython的GC都可能延迟回收。
解决思路不是强行调用__del__，而是预防或干预：
- 优先用
weakref.ref替代强引用（如self.parent = weakref.ref(parent)） - 在关键路径末尾显式置
None（如self.child = None），打破引用环 - 调试时可用
import gc; gc.get_referrers(obj)查谁还引用着它 - 极少数场景需强制回收：调用
gc.collect()，但这是性能敏感操作，不应常态使用
真正难处理的从来不是“怎么销毁”，而是“为什么还活着”——盯着引用链，比盯着__del__有用得多。
