__del__ 不可靠，仅在引用计数归零且无循环引用时可能调用；循环引用会导致其永不执行；解释器退出时易因全局对象销毁而异常；应优先使用 with 语句和 __exit__ 进行确定性资源清理。
__del__ 不是“对象离开作用域时就触发”，也不是“程序结束前必调用”——它只在对象被垃圾回收器真正销毁内存时才可能执行，且时机不可控、不可靠。
__del__ 触发的前提是引用计数归零，但不等于“变量被 del”
很多人以为 del t 就等于“立刻销毁对象并调用 __del__”，其实 del t 只是解除变量 t 对对象的引用，让该对象的引用计数减 1。只有当引用计数真正降到 0，且没有循环引用干扰时，CPython 才可能立即调用 __del__。
-
del t后若还有其他变量（如u = t）或容器（如lst = [t]）持有该对象，__del__不会触发 - 全局变量、模块级变量生命周期长，即使函数返回，其引用仍存在，
__del__往往拖到解释器退出才尝试调用 - CPython 中，纯引用计数机制下能及时触发；但一旦涉及循环引用（比如 A 持有 B，B 又持有 A），就得等周期性垃圾回收器（GC）介入，而 GC 不保证立即运行
为什么 __del__ 在解释器退出时行为异常
解释器关闭阶段，模块全局命名空间被清空，对象引用批量失效，但此时 Python 已开始销毁内置类型和模块，__del__ 中若访问任何全局名（如 print、sys、自定义模块函数），大概率抛出 AttributeError 或静默失败——因为那些名字已经不存在了。
- 常见错误现象：
Exception ignored in: <function test.__del__ at></function>+AttributeError: 'NoneType' object has no attribute 'write' - 根本原因：标准输出
sys.stdout等对象在__del__被调用前已被设为None - 即便你把清理逻辑写得再简单，也无法规避解释器终止顺序带来的不确定性
循环引用会让 __del__ 彻底失效
只要两个或多个对象互相持有对方的引用（比如观察者模式中对象双向绑定、树节点父子互引），它们的引用计数就永远 > 0，纯引用计数机制无法释放它们，只能靠 GC 模块扫描回收。而 CPython 的 GC 在发现含 __del__ 的对象构成循环时，会直接将其移入 gc.garbage 列表，永不调用 __del__ ——这是明确的设计行为，不是 bug。
立即学习“Python免费学习笔记（深入）”；
- 验证方式：导入
gc，执行gc.collect()后检查gc.garbage是否非空 - 哪怕手动调用
gc.collect()，含__del__的循环引用对象也不会被清理，只会滞留在garbage中 - 这种情况下，资源（如打开的文件描述符、socket 连接）将一直泄漏，直到进程结束
替代方案：用 __exit__ 配合 with，而不是依赖 __del__
所有需要确定性清理的场景（文件、锁、数据库连接、临时目录），都应优先走上下文管理器路径。它不依赖垃圾回收，而是由 with 语句块退出时**强制、同步、可预测**地触发清理逻辑。
- 自定义类只需实现
__enter__和__exit__，不用碰__del__ - 已有资源类（如
open()、threading.Lock()）天然支持with，直接用就行 - 若必须兜底（极少数情况），可在
__del__里加日志警告：“资源未通过 with 正确释放”，而不是尝试做实质清理
真正难处理的从来不是“怎么写 __del__”，而是“如何避免依赖它”。一旦你开始查 gc.garbage 或捕获 Exception ignored in 日志，说明设计上已经绕进了不可靠路径。
