应使用 weakref.finalize 或上下文管理器实现对象销毁快照，避免依赖不可靠的 __del__；前者确保回调在回收时安全执行，后者通过 __exit__/finally 显式控制，二者均支持容错、测试与可观测性。
在对象被垃圾回收前捕获其最终状态并持久化（如写入日志、数据库或内存缓存），不能依赖常规的析构逻辑（如 Python 的 __del__ 或 Java 的 finalize），因为它们不可靠、不及时、甚至被弃用。真正可行的方式是结合弱引用（weakref）与终结器（weakref.finalize）或显式资源管理（如上下文管理器/try-finally），在对象生命周期终点**安全、可控、可测试**地触发快照存储。
用 weakref.finalize 实现可预测的回收快照
Python 中 weakref.finalize 是目前最推荐的方式：它不阻止对象回收，但确保回调在对象被销毁时（且仅一次）执行，且支持注册/取消、传参、异常隔离。
- 定义快照函数，接收对象实例及所需字段名，序列化后存入文件或发送到监控系统
- 在对象初始化时注册 finalize 回调，绑定当前实例和快照参数
- 回调中避免强引用原对象（否则会阻止回收），只读取已知属性或提前缓存的关键值
- 示例：obj = MyResource(name="db-conn", active_queries=3); weakref.finalize(obj, take_snapshot, obj.name, obj.active_queries)
通过上下文管理器+finally 显式控制快照时机
对关键资源类（如数据库连接、临时文件句柄），优先使用 with 语句配合 __enter__/__exit__，在 __exit__ 或 finally 块中完成快照——这是最稳定、可调试、符合 RAII 的方式。
- 在
__exit__中直接读取对象当前属性，调用json.dump或写入本地日志文件 - 若需异步落盘（如发 HTTP 请求），建议设超时并吞掉非关键异常，防止阻塞退出
- 比
__del__更可靠：不依赖 GC 时机，也不受循环引用影响
避免陷阱：为什么 __del__ 不适合快照存储
__del__ 在 CPython 中看似可用，但存在多个硬伤：
- 执行时机不确定：可能延迟到解释器关闭，甚至不执行（如模块全局变量被清空时）
- 无法安全调用外部 I/O：此时模块可能已被卸载，
open、requests等会抛ImportError或AttributeError - 禁止在
__del__中引发未捕获异常，否则会被静默丢弃，难以排查 - 与
weakref或循环引用交互时行为复杂，易导致内存泄漏或崩溃
进阶：带重试与降级的快照策略
生产环境需考虑快照失败场景。可在 finalize 或上下文退出时嵌入轻量级容错逻辑：
- 首次尝试同步写入本地 JSON 文件；失败则转为追加到环形内存缓冲区（
collections.deque） - 另起低优先级线程定期刷出缓冲区内容（注意线程安全）
- 添加简单哈希校验（如
hashlib.md5(json.dumps(state).encode())）防止快照损坏 - 记录快照是否成功到指标（如
snapshot_success_total{type="MyResource"} 1）便于观测
