sys.getsizeof() 对自定义类返回值偏低，因其仅计算实例头和 dict 本身大小，不递归统计引用对象；pympler.asizeof.asizeof() 可深度估算，而精确测量需用 tracemalloc 差分快照。
为什么 sys.getsizeof() 对自定义类返回的值往往严重偏低
sys.getsizeof() 只计算对象顶层结构的内存，不递归统计内部引用对象（如列表、字典、嵌套实例）所占空间。对 list 或 dict 这类内置容器，它会额外调用其内部的 __sizeof__ 实现并包含缓冲区，但对用户定义的类（哪怕只是存了一个 list），它默认只返回实例头 + 实例字典（__dict__）本身的大小，而 __dict__ 里存的仍是引用——实际数据还在别处。
常见错误现象：
- 定义一个含 10 万个整数的 MyContainer 类实例，sys.getsizeof() 返回 56 字节；
- 直接用 list(range(100000)) 则返回约 800 KB；
- 二者实际驻留内存几乎一致，但前者看起来“轻如鸿毛”。
用 pympler.asizeof.asizeof() 做近似深度估算
pympler 是目前最实用的第三方方案，asizeof.asizeof() 会递归遍历对象图，对常见类型（list、dict、tuple、set、str、bytes、用户类实例等）做类型感知的尺寸计算，并跳过循环引用。
- 安装：
pip install pympler - 基本用法：
from pympler import asizeof; asizeof.asizeof(my_obj) - 对含大量嵌套或自引用的结构，可加
limit=1000防止栈溢出 - 注意：它不计算 C 扩展对象（如 NumPy 数组底层 buffer）的精确值，而是按 Python 对象视图估算；对
array.array或bytearray会更准
手动递归统计时必须绕开的三个陷阱
自己写递归 __sizeof__ 很容易翻车，核心难点不在遍历，而在识别和排除重复/非法引用。
- 忽略
__slots__：若类定义了__slots__，实例没有__dict__，直接访问会报AttributeError；需用getattr(obj, '__slots__', ())并逐个取值 - 误算弱引用或代理：
weakref.ref、weakref.WeakKeyDictionary等不应计入目标对象内存，但默认会被vars()或__dict__暴露出来 - 陷入无限循环：两个对象互相持有对方引用（A→B→A），不维护已访问 ID 集合（
id(obj)）会导致 RecursionError
示例片段（仅示意逻辑，非完整实现）：
seen = set(); def deep_size(obj):<br> if id(obj) in seen: return 0<br> seen.add(id(obj))<br> size = sys.getsizeof(obj)<br> if hasattr(obj, '__dict__'): size += deep_size(obj.__dict__)<br> # ……其他分支
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
立即学习“Python免费学习笔记（深入）”；
真正需要精确值时：只能靠 tracemalloc + 差分快照
当你的自定义结构会触发大量临时对象分配（比如解析过程中生成中间字符串、缓存字典），或者涉及 C 扩展（如 pandas DataFrame、torch.Tensor），asizeof 的估算会明显偏离真实堆占用。这时唯一可靠的方式是让 Python 解释器自己记账。
- 启用追踪：
import tracemalloc; tracemalloc.start() - 在操作前后分别调用
tracemalloc.take_snapshot() - 用
snapshot2.compare_to(snapshot1, 'lineno')查看新增内存最多的代码行 - 关键点：必须确保被测对象是**唯一活跃的新分配源**，否则差分结果混杂其他干扰项
这方法不返回“某个变量占多少”，而是告诉你“这段代码执行期间，Python 堆多用了多少字节”——这才是生产环境里真正影响 GC 压力和 OOM 风险的数字。
自定义类的内存评估没有银弹；asizeof 快且够用，但一旦涉及 C 层、缓存策略或生命周期复杂的对象图，就得退回到 tracemalloc 的观测视角——它不解释结构，只忠实地记录解释器到底拿了多大一块堆。
