__del__ 方法不可靠，因其触发时机由垃圾回收器决定且受引用计数和循环引用影响，常不被调用；禁止在其中执行依赖外部对象或I/O的操作；应优先使用上下文管理器（with）或weakref.finalize。
Python 中 __del__ 方法不可靠，不应用于关键资源释放（如文件、网络连接、数据库事务），它不是 C++ 的析构函数。它的触发时机由垃圾回收器决定，且在解释器退出时行为不确定；真正需要确定性清理的场景，应优先用上下文管理器（with）或显式 close() 方法。
为什么 __del__ 常常不被调用？
Python 使用引用计数为主 + 循环检测为辅的垃圾回收机制。__del__ 只在对象引用计数归零且无循环引用时才可能执行。常见失效场景包括：
- 对象被全局变量、模块级字典或日志缓存等意外持有（引用计数不为 0）
- 对象参与了循环引用（例如 A 持有 B，B 又持有 A），而该循环未被 gc 模块及时清理
- 程序直接调用
os._exit()或发生严重错误导致解释器强制终止 - 主线程结束时，其他线程中创建的对象可能来不及触发
__del__
__del__ 中禁止哪些操作？
因为调用时机不可控，__del__ 内部不能依赖任何“此时其他对象还活着”的假设。以下操作极易引发异常或静默失败：
- 访问其他模块中的全局对象（模块可能已被清空，抛
AttributeError或ImportError） - 调用
print()、logging.info()等依赖标准流或 logger 实例的方法（这些对象可能已销毁） - 启动新线程、发起网络请求、写入文件（I/O 可能被关闭，或引发
RuntimeError） - 调用其他对象的非平凡方法（对方可能已在
__del__链中被销毁）
最安全的做法是只做极轻量的本地状态标记，比如设置一个 self._closed = True，或仅调用内置函数如 sys.stdout.flush()（但依然不推荐）。
立即学习“Python免费学习笔记（深入）”；
替代方案：用 __enter__/__exit__ 或 contextlib.closing
若你本意是确保某资源被释放（如临时文件、锁、socket），正确做法是让类支持上下文管理协议：
class ManagedResource:
def __init__(self, path):
self.path = path
self.file = open(path, 'w')
<pre class="brush:php;toolbar:false;">def __enter__(self):
return self
def __exit__(self, exc_type, exc_val, exc_tb):
if hasattr(self, 'file') and not self.file.closed:
self.file.close() # 这里才是可靠的清理点使用方式（保证执行）
with ManagedResource('/tmp/data.txt') as res: res.file.write('hello')
→ 退出 with 块时，exit 必然被调用
对已有类（如 sqlite3.Connection），可直接套 contextlib.closing：
from contextlib import closing
import sqlite3
<p>with closing(sqlite3.connect('db.sqlite')) as conn:
conn.execute('INSERT INTO ...')</p><h1>conn.close() 自动触发</h1><p>真正难处理的是跨进程或需与 C 扩展交互的资源——这时得结合 atexit.register()（注意：它也不 100% 可靠，但比 __del__ 更可控），或改用弱引用回调（weakref.finalize），后者是 Python 3.4+ 推荐的、更明确的替代方案。
