为什么 del 之后内存不立即释放？
Python 的内存回收依赖引用计数 + 垃圾收集器（gc），del 只是减少引用计数，并不保证立刻归还内存给操作系统。尤其当对象被循环引用、或位于大容器中未被完全清理时，gc.collect() 也未必能马上触发释放。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
sys.getsizeof()查对象本身内存（不含子对象），配合obj.__dict__或vars()检查大字段；不要只看del是否执行成功 - 对已知生命周期的大型数据结构（如临时 DataFrame、缓存字典），显式调用
gc.collect()后再检查psutil.Process().memory_info().rss - 避免在长生命周期对象（如类实例、模块级变量）中持有短命大数据的引用——这是最隐蔽的内存泄漏源
如何安全地复用 list 和 dict 而不反复分配？
频繁创建/销毁中等大小容器（比如每次请求生成几千项的 list）会带来显著分配开销和内存碎片。工程上更优的做法是「池化」或「预分配+清空」。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
list.clear()替代重新赋值my_list = []：前者复用底层数组内存，后者触发新分配 - 对固定上限场景（如日志缓冲区），初始化时用
[None] * N预占空间，再用索引写入 +del list[:used_len]截断 -
dict不支持.clear()复用底层哈希表结构（CPython 3.12+ 开始优化，但旧版本仍会逐步扩容缩容），可考虑改用collections.OrderedDict或第三方simplejson的池化工具
哪些 __slots__ 场景真正节省内存？
__slots__ 对单个实例节省有限（约 48–96 字节），但当创建数十万以上实例（如 ORM 模型、解析后的 AST 节点）时，累积效果明显——关键是它禁用 __dict__，阻止动态属性写入。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 仅在明确知道实例数量级且属性名固定的类中启用，比如
class Event: __slots__ = ('ts', 'user_id', 'action') - 若需兼容动态属性（如调试用
obj.debug_info = ...），可用__slots__ = ('__dict__', 'ts', 'user_id')折中，但失去大部分内存优势 - 注意继承：父类定义了
__slots__，子类也必须定义，否则子类实例仍会创建__dict__
用 array.array 还是 numpy.ndarray 存数值？
纯 Python 数值列表（list[int]）每个元素都是整数对象指针，内存开销巨大；array.array('i') 是紧凑 C 风格数组，numpy.ndarray 更进一步支持向量化与视图机制。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 无计算需求、仅存储/序列化：优先
array.array（标准库、零依赖、比list节省 90%+ 内存） - 需切片、广播、数学运算：必须用
numpy.ndarray，但注意np.copy()显式复制 vsarr[100:200]返回视图——后者不占新内存，但可能意外延长原数组生命周期 - 警惕
numpy.array(list_of_python_objects)：这反而比原list更耗内存，应先确保输入是原始数值类型
真实项目里，内存问题往往不是某一行代码导致的，而是多个小选择叠加的结果：一个没清空的缓存字典、十万个没加 slots 的模型实例、每次解析都新建的 list ——它们各自看起来无害，合起来就让 RSS 翻倍。盯住数据生命周期，比调 gc.collect() 有用得多。
