sys.getsizeof仅返回对象自身结构体大小，不包含其引用的子对象内存；真实总内存需用pympler.asizeof或tracemalloc分析。
sys.getsizeof 返回的只是对象本身，不包括引用对象
sys.getsizeof 测量的是 Python 对象在内存中的“直接占用”，比如一个 list 对象本身的结构体大小（指针、长度字段等），但不会递归计算它所引用的元素（如内部的 int、str）占多少。这意味着对容器类对象（list、dict、tuple）调用 sys.getsizeof，结果往往远小于你直觉认为的“总内存”。
常见错误现象：
– sys.getsizeof([1, 2, 3]) 返回约 80 字节，而三个 int 各占 28 字节，加起来应超 100 字节 —— 实际上列表只存了三个指针，每个 8 字节（64 位系统），主体结构开销占大头；
– sys.getsizeof("hello") 返回 54，是因为字符串对象自身含长度、哈希缓存、引用计数等字段，不是纯字符数组长度 × 1。
想测“真实总内存”，得手动递归 + 去重避免重复计数
Python 没有内置的深内存测量函数，但可以用 gc.get_referents 和 id() 手动遍历引用链。关键点是：必须用集合记录已访问对象的 id，否则循环引用（如 obj.attr = obj）会导致无限递归或重复累加。
实操建议：
立即学习“Python免费学习笔记（深入）”；
调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强，支持文件上传与图片 URL 输入。
- 从目标对象开始，用
gc.get_referents(obj)获取它直接引用的对象列表 - 对每个未见过的引用对象，递归调用并累加
sys.getsizeof - 跳过内置类型（如
type、function、module）——它们的sys.getsizeof可能返回 0 或异常值，且通常不计入用户数据内存 - 注意：某些对象（如
numpy.ndarray）内部内存由 C 分配，sys.getsizeof无法反映其 buffer 大小，需调用.nbytes等专用属性
字符串和小整数的内存表现很特殊
CPython 对小整数（-5 到 256）和短字符串做了缓存/驻留优化，导致 sys.getsizeof 行为反直觉：
- 多个相同小整数变量（如
a = 10; b = 10）共享同一对象，但sys.getsizeof(a)仍返回单个int的大小（28 字节），不是“共享节省了多少” - 短字符串（如
"abc"）可能被驻留，但sys.getsizeof不体现驻留状态，只返回该字符串对象自身的开销（含字符数据） - 长字符串（> 4096 字节）会触发单独的内存分配策略，
sys.getsizeof结果可能包含额外 padding，不一定严格等于len(s) + 开销
所以别指望靠 sys.getsizeof 推断对象是否被复用 —— 它只回答“这个对象自己占多少”，不回答“整个程序里这类对象共占多少”。
实际调试时，优先用 memory_profiler 而非手写递归
手动实现深内存测量容易漏掉边界情况（比如 __slots__ 类、弱引用、C 扩展对象），而且性能差。更可靠的做法是用 memory_profiler 包的 memory_usage 或行分析模式：
- 安装：
pip install memory-profiler - 快速比对两个对象：
from memory_profiler import memory_usage; mem1 = memory_usage()[0]; obj = big_dict(); mem2 = memory_usage()[0]; print(mem2 - mem1) - 对函数逐行测内存：
@profile装饰器 +python -m memory_profiler script.py
它的底层用了 /proc/self/statm（Linux）或 psutil（跨平台），反映的是进程级真实 RSS 内存变化，比纯 Python 递归模拟更贴近实际压力场景。
真正难处理的是跨模块引用、C 扩展持有的内存、以及 mmap 映射区域 —— 这些连 memory_profiler 都覆盖不到，得结合 tracemalloc（跟踪 Python 堆分配）或系统级工具（如 valgrind --tool=massif）来看。
