sys.getsizeof()不能直接用于生产环境内存诊断，因其仅计算对象本身结构体大小，不递归统计所引用子对象内存，易导致严重误判；需配合asizeof和tracemalloc组合分析。
sys.getsizeof() 为什么不能直接用于生产环境内存诊断
sys.getsizeof() 只返回对象本身的内存开销，不递归计算它持有的子对象。比如一个包含 1000 个字符串的字典，sys.getsizeof(my_dict) 可能只报 248 字节，但实际总占用可能是几 MB——这部分完全被忽略。
它对内置容器（list、dict、tuple）只统计结构体大小，键值对的内存由各自独立分配，且不计入；对自定义类实例，也不包含其 __dict__ 中属性对象的体积。
常见错误现象包括：监控显示“字典很小”，但进程 RSS 持续上涨；用 getsizeof() 对比两个对象后认为 A 比 B 节省内存，结果上线后 A 反而更吃内存。
- 仅适合快速估算单层对象结构体大小（如空
dict是 248 字节，空list是 56 字节） - 不适用于嵌套深、引用多、含大量字符串或 bytes 的场景
- 在 CPython 3.12+ 中行为稳定，但不同小版本间数值可能浮动 ±8 字节
asizeof.asizeof() 在 Pympler 中的实际调用方式
asizeof.asizeof() 是 Pympler 提供的递归深度测量函数，它会遍历对象图（object graph），把所有可达对象的 getsizeof() 结果加总，并去重避免重复计数（例如多个变量引用同一列表）。
立即学习“Python免费学习笔记（深入）”；
使用前需安装：pip install pympler。注意不要用 pip install Pympler（旧包名已弃用，会装错版本）。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 默认行为已足够健壮：自动跳过循环引用、C 扩展对象（如
numpy.ndarray底层 buffer）、以及不可达的中间帧 - 支持限深：
asizeof.asizeof(obj, limit=10)防止栈溢出或卡死在超大嵌套结构中 - 可排除特定类型：
asizeof.asizeof(obj, code=False, module=False)忽略函数代码对象和模块对象，减少干扰 - 不推荐在热路径（如每秒调用数百次的 API 内）直接使用，因递归遍历有可观开销（平均比
getsizeof慢 20–50 倍）
生产环境部署 asizeof 的三个关键约束
在高并发服务中直接用 asizeof.asizeof() 打点，容易引发性能抖动或内存误判。必须配合明确的上下文控制。
- 不要在请求处理主流程中实时调用——改为采样模式：比如每 1000 次请求抽 1 次，或仅在 debug header 存在时触发
- 避免对整个 Flask/FastAPI
request.state或 Djangorequest对象整块测量——它们自带大量闭包、绑定方法、中间件栈，结果不可比且易爆炸。应聚焦具体缓存字段、序列化 payload、ORM 查询集结果等目标对象 - 注意
asizeof不跟踪 C 层内存：若对象含numpy.array、torch.Tensor、cv2.Mat等，其底层 buffer 不会被计入，需额外用.nbytes或.element_size() * .nelement()补充
替代方案：tracemalloc + asizeof 组合定位泄漏源头
单独用 asizeof 只能告诉你“现在这个对象有多大”，但无法回答“它为什么变大了”或“是谁反复创建它”。这时候要搭配 tracemalloc。
典型做法是：在服务启动时调用 tracemalloc.start(25)（保留 25 帧调用栈），然后定期执行：
snapshot = tracemalloc.take_snapshot()
stats = snapshot.statistics('lineno')
for stat in stats[:5]:
print(stat)再结合 asizeof 对 top 3 的分配点对应对象做深度测量，就能确认是缓存没清理、生成器没消费完、还是某个 class 实例意外持有了大附件。
容易被忽略的一点是：tracemalloc 默认只记录 Python 层 malloc，不包括 mmap 分配（如某些数据库驱动）、也不包括子进程内存。如果你观察到 RSS 上涨但 tracemalloc 无热点，大概率是外部库在 C 层偷偷 malloc 了。
