Python traceback.clear_frames：保存报错以后，局部对象为什么迟迟没有释放
批处理把失败时的 traceback 对象放进列表，准备最后统一汇报。失败函数已经返回，里面的大对象却仍然活着，累计几百次后占用明显增加。这个现象不一定是垃圾回收失效：保存的回溯仍然指向栈帧，栈帧又可能留着局部变量。需要先追踪引用关系，再决定要保留多少诊断现场。
只用小对象演示引用链
下面故意创建一个没有大块数据的 Payload，用 weakref.ref 观察它是否还活着。弱引用只用于观察，不会自己把目标保活。保存为 demo.py，运行 python demo.py。capture 函数返回时已经结束执行，之后才清理它保存的回溯，避免把正在运行的帧混入演示。
import gc
import traceback
import weakref
class Payload:
pass
def capture():
payload = Payload()
observer = weakref.ref(payload)
try:
raise RuntimeError("demo")
except RuntimeError as error:
return error.__traceback__, observer
saved, observer = capture()
gc.collect()
print("before:", observer() is not None)
assert observer() is not None
traceback.clear_frames(saved)
gc.collect()
print("after:", observer() is not None)
print("frames:", [frame.name for frame in traceback.extract_tb(saved)])
assert observer() is None
assert saved is not None输出先显示 before 为 True，clear_frames 之后 after 为 False。保存的回溯对象仍然存在，frames 仍能列出函数名 capture。这说明清理局部变量与删除整个 traceback 不是同一个动作。代码再次调用垃圾回收只为了使实验步骤清楚，并不证明生产中需要在每次异常后强行触发回收。
清理之前先决定需要的诊断信息
clear_frames 的目标是回溯所关联栈帧里的局部变量。执行后，依靠这些变量做事后调试的能力会减少，所以应在你已经完成必要的诊断提取、且相关函数不再运行时使用。若只需要错误类型、消息、文件和行号，可以考虑先保存更轻的摘要，而不是长期保留完整执行现场。
AI生成概念示意图：回溯仍然保留结构，清理的是帧连接到局部对象的引用。
标准库的 TracebackException 提供适合延后格式化的表示，目的之一是避免持续持有 traceback 和 frame 引用。需要记录局部值时，还应考虑体积与信息范围；异常现场常包含输入内容。不要为了解决内存问题，又把所有局部对象转成完整字符串塞进日志，造成另一种无法控制的存储增长。
一次清理不能释放所有引用
本例把 Payload 只放在演示帧的局部变量里，所以结果非常直接。真实系统还可能有缓存、全局列表、异常对象自带属性或其他闭包持有同一对象。清掉栈帧引用后，只要另一个强引用存在，对象就仍然不会消失。应继续查明持有者，不能仅凭内存曲线没有下降就断言方法失效。
对象变得不可达也不等于操作系统立刻收回同样多的进程内存。解释器分配器可能保留已经释放的空间供以后复用，内存统计还受对象类型和运行环境影响。因此本文用弱引用验证生命周期，不用一个很小的进程内存差值推导性能收益，也不把“after 为 False”包装成通用的降内存比例。
清理正在执行的帧另有约束，不能把函数中任何时刻拿到的回溯都当成可以随意清空的容器。最容易维护的时机，是异常已经离开工作函数，诊断材料已经收集，且后续不会依赖它的局部值时。需要交给调试器继续检查的错误，应先遵守调试流程，而不是自动清理掉需要的证据。
最后区分业务资源关闭与对象引用释放。打开的文件、锁和连接应该通过明确的上下文或 finally 管理，不能等待报错对象最终消失才指望资源归还。clear_frames 可以减少诊断对象的连带保活，但不替代资源生命周期设计。验收时同时检查摘要是否可用、观察对象是否释放，以及清理后没有继续读取局部值的步骤。
资料核对日期：2026年10月2日（北京时间）。示例在 Python 3.12.14 中独立运行，具体输出以本文实测为准。
