__del__ 不适合释放非托管资源，因其调用时机不可控、可能因循环引用不执行、模块卸载后访问属性会失败，且多线程下无上下文保障；正确做法是用 __enter__/__exit__ 或显式 close()。
Python 的 __del__ 方法不是可靠的资源清理入口，它不能保证被调用，也不该用于释放关键非托管资源（如文件句柄、网络连接、C 扩展分配的内存）。
为什么 __del__ 不适合释放非托管资源
Python 的垃圾回收基于引用计数 + 循环检测，而 __del__ 的触发时机不可控：可能在程序退出时才执行，也可能因循环引用永远不执行；更严重的是，解释器开始销毁模块全局变量后，__del__ 中若再访问已卸载的模块或函数（比如 os.close），会直接静默失败或抛出 AttributeError。
常见错误现象：__del__ 里调用 self.file.close() 却报 AttributeError: 'NoneType' object has no attribute 'close' —— 因为 self.file 已被设为 None 或模块已解构。
-
__del__不是析构函数，没有“对象销毁前必执行”的语义保障 - 多线程环境下，
__del__可能在任意线程中被调用，无法依赖 TLS 或当前上下文 - CPython 3.12+ 进一步限制了
__del__中可安全调用的内置函数范围
正确做法：用 __enter__/__exit__ + contextlib.closing 或显式 close()
非托管资源必须由使用者显式释放，最可靠路径是让类实现上下文管理协议，强制用户用 with 块；若无法修改调用方，则提供明确的 close() 方法并文档强调“必须调用”。
立即学习“Python免费学习笔记（深入）”；
示例（正确模式）：
class ResourceManager:
def __init__(self, fd):
self._fd = fd # 假设是 os.open 返回的整数句柄
<pre class='brush:python;toolbar:false;'>def close(self):
if hasattr(self, '_fd') and self._fd is not None:
try:
os.close(self._fd)
except OSError:
pass
finally:
self._fd = None
def __enter__(self):
return self
def __exit__(self, *exc):
self.close()使用方式（推荐）
with ResourceManager(os.open("/tmp/test", os.O_RDWR)) as res:
do something
pass # 自动 close()
或手动调用（需严格守约）
res = ResourceManager(os.open("/tmp/test", os.O_RDWR)) try:
do something
pass
finally: res.close() # 必须写
特殊情况：C 扩展中分配的内存如何处理
若类封装了 C 层 malloc 分配的内存（如通过 cffi 或 ctypes 调用），且无法用 RAII 封装进 Python 对象生命周期，__del__ 是最后手段，但必须加防护：
- 只在
__del__中调用 C 函数释放，不访问任何 Python 对象（包括self的其他属性） - 用
try/except包裹释放调用，并忽略所有异常（包括SystemError和AttributeError） - 优先改用
weakref.finalize—— 它比__del__更可控，且允许指定清理函数独立于实例存活状态
示例（用 finalize 替代）：
import weakref import ctypes <p>class CBuffer: def <strong>init</strong>(self, size): self.buf = ctypes.cast( ctypes.malloc(size), ctypes.POINTER(ctypes.c_char * size) )</p><h1>绑定清理逻辑到对象弱引用，不依赖 self 存活</h1><pre class='brush:python;toolbar:false;'> self._finalizer = weakref.finalize(self, ctypes.free, self.buf) # __del__ 留空或仅作日志，不执行释放
容易被忽略的关键点
很多人以为只要写了 __del__ 就算“做了资源管理”，实际上真正危险的是：它给了虚假的安全感。最常被忽略的是——
- 测试时一切正常，但生产环境因模块卸载顺序、解释器 shutdown 阶段或 PyPy/Jython 行为差异，
__del__根本不运行 - 把
__del__当成兜底，反而疏于在业务逻辑中插入close()或with，导致资源泄漏在高频短生命周期对象上快速累积 - 在
__del__里打印日志调试，结果发现日志根本没输出，误判为“没触发”，其实是因为解释器已禁用 stdout
