__del__ 方法不可靠，不能用于关键资源清理，因其调用时机不确定、可能不被调用，甚至在解释器关闭时引发异常；应使用显式close()、with语句或上下文管理器替代。
Python 的 __del__ 方法不是可靠的析构函数，**不能用于关键资源清理**，主要因为其调用时机不确定、可能不被调用，甚至在解释器关闭阶段引发异常。
调用时机完全不可控
Python 依赖引用计数和垃圾回收（GC）机制决定对象何时被销毁。__del__ 只在对象的引用计数归零且未被循环引用困住时才可能触发；若对象参与了循环引用，需等待 GC 轮次，而 GC 时间不可预测。更严重的是，在程序退出时，模块全局变量可能已被清空，此时若 __del__ 尝试访问已卸载模块中的函数或类，会直接抛出 AttributeError 或静默失败。
无法保证执行，也不适合做关键清理
以下情况 __del__ 根本不会运行：
- 程序被
os._exit()强制终止 - 发生致命错误（如段错误）导致解释器崩溃
- 对象在解释器关闭过程中仍存活（此时模块命名空间已破坏）
- 多线程环境下，主线程退出而子线程仍持引用
因此，绝不要把文件关闭、数据库连接释放、锁释放等关键操作放在 __del__ 中。
立即学习“Python免费学习笔记（深入）”；
推荐替代方案：显式管理 + 上下文协议
可靠的做法是主动控制生命周期：
- 提供明确的
close()、shutdown()等方法，并在文档中强调必须调用 - 实现
__enter__和__exit__，支持with语句（自动确保清理） - 对文件、网络连接等资源，优先使用标准库自带的上下文管理器（如
open()、socket.socket()） - 必要时结合
atexit.register()做进程退出前的兜底处理（但仍有局限，不能替代显式清理）
如果真要用 __del__，务必谨慎
仅限于日志记录、调试计数、非关键状态标记等“尽力而为”场景。编写时注意：
- 避免访问模块级变量或其它可能已被销毁的对象
- 不要在其中调用可能抛异常的代码（异常会被忽略并打印警告）
- 避免在
__del__中重新创建强引用（可能导致对象无法回收） - 测试时需覆盖解释器退出、循环引用、异常中断等多种边界情况
不复杂但容易忽略。
