闭包本身不直接暴露内存占用数值，python无内置api获取其字节数；关键在于通过__closure__分析捕获变量，识别是否意外持有大型对象导致内存泄漏。
闭包本身不直接暴露“占用多少字节”的数值，Python 没有内置 API 能一键返回某个闭包对象占用了多少堆内存。但你可以通过分析其引用关系和捕获变量来合理估算和监控——关键不是算绝对值，而是识别它是否在不该存在时还持续持有着大对象。
看闭包捕获了什么
闭包的内存开销主要来自 __closure__ 中保存的 cell 对象所引用的外部变量。这些变量只要被内部函数引用着，就不会被释放。
- 用
func.__closure__查看是否非空：空则无闭包，不额外占内存 - 遍历
func.__closure__，对每个cell.cell_contents调用sys.getsizeof()—— 这给出该值本身的内存大小（注意：对容器如 list/dict，这只是浅层大小，不含内部元素） - 特别留意是否捕获了大型对象：比如 pandas DataFrame、numpy 数组、长列表、打开的文件句柄等，它们才是真正的内存大户
区分“闭包结构”和“捕获内容”
闭包函数对象自身（如 add_5）非常轻量，通常几百字节；真正吃内存的是它“记住”的那些数据。
- 函数对象本身可用
sys.getsizeof(func)测量，但意义不大 - 重点检查
func.__closure__[i].cell_contents—— 如果是字符串、数字，影响微乎其微；如果是 10MB 的图片 bytes 或 100 万行的日志列表，那就是隐患 - 如果捕获的是另一个闭包或类实例，需递归检查其持有的资源
结合 gc 和对象追踪定位泄漏
当怀疑闭包导致内存持续增长，单看一个闭包不够，要放在整体中观察：
- 用
gc.get_objects()筛出所有函数对象，再过滤出有__closure__的，统计它们捕获内容的类型和大小分布 - 对比不同时间点的
gc.get_count()和len(gc.get_objects())，看是否大量闭包函数长期存活 - 配合
objgraph库：画出谁引用了某个疑似泄漏的大对象，常能发现是某个闭包意外持有了它
实际监控建议
不要追求精确字节数，而要建立可操作的检查逻辑：
- 在关键闭包创建处加日志：记录捕获的变量类型和长度（如
len(data) if hasattr(data, '__len__')） - 对已知高风险闭包（如缓存装饰器、状态管理回调），定期调用
sys.getsizeof(closure.__closure__[0].cell_contents)做阈值告警 - 避免在闭包中捕获整个对象实例；改用 ID、键名或只捕获必要字段
不复杂但容易忽略：闭包内存问题 rarely 是闭包语法本身的问题，而是它无意中延长了本该短期存在的大数据对象的生命周期。
