MemoryError本质是进程连续内存分配超限，优化须聚焦数据处理过程：用pd.read_csv(chunksize+dtype+usecols)控加载、yield实现惰性计算、del+gc.collect()清理大对象、np.memmap替代全载入，并以memory_profiler定位峰值。
MemoryError 出现时，不是“内存不够用”的模糊判断，而是 Python 明确告诉你：**当前操作试图分配的连续内存块，超出了操作系统能给这个进程划出的上限**。它往往发生在数据加载、中间计算或对象复制阶段，而非最终结果本身——也就是说，优化方向必须落在“过程”上，而不是等报错后再扩容。
pd.read_csv(chunksize=) 为什么必须配 dtype 和 iterator=True
只设 chunksize 不够，pandas 默认仍会为每块做全量类型推断，对字符串列自动设为 object，内存开销翻倍。常见错误是写成：
pd.read_csv('big.csv', chunksize=50000)
正确做法是显式约束类型：
-
dtype参数必须传字典，例如{'user_id': 'category', 'score': 'float32'}，避免object类型； -
iterator=True是隐式要求，不写也能用，但加上更清晰，防止误用成一次性读取； - 跳过无用列用
usecols，比如usecols=['id', 'value']，直接从磁盘过滤，不进内存； - 如果源文件有重复索引或冗余 header，加
skiprows或header=None避免额外解析开销。
生成器 yield 不是语法糖，是内存控制开关
把 return [x*2 for x in range(10**7)] 改成 yield，不是为了“看起来高级”，而是让 Python 完全跳过构建完整列表的过程。关键点在于：
- 函数体内只要出现
yield，就变成生成器函数，调用后返回generator对象，不执行任何逻辑； -
for item in gen_func()才真正触发单次计算，且上一轮的局部变量（包括循环变量）在 yield 后即被释放； - 不能对生成器做
len()、list()或索引访问，否则立刻转成内存驻留结构，前功尽弃； - 配合
itertools.islice(gen, start, stop)可安全截取片段，不破坏惰性。
del + gc.collect() 在什么场景下真有用
手动触发垃圾回收不是万能药，但在明确的大对象生命周期边界处，它能防止引用残留拖慢回收节奏。典型有效场景：
立即学习“Python免费学习笔记（深入）”；
- 处理完一个
pd.DataFrame后立即del df，再gc.collect()，尤其当后续要加载另一个同量级数据时； - 多层嵌套字典或自定义类实例中含大量子对象，且确认无外部引用时；
- 使用
multiprocessing时，子进程退出后主进程里残留的shared_memory或Queue对象，需主动close()并del； - 注意：
gc.collect()返回值是回收的不可达对象数量，若长期为 0，说明没泄漏，别硬刷。
NumPy 数组的 .memmap() 不是备选方案，是默认选项
当数组尺寸接近或超过可用内存的 30%，就该默认考虑 np.memmap。它不是“把数组存到硬盘”那么简单，而是让 OS 管理页交换，Python 层面仍像普通数组一样切片、索引：
- 创建时指定
mode='r'（只读）或'c'（copy-on-write），避免意外写入污染原文件； - 路径必须是真实文件路径，不能是临时
BytesIO； - 形状和 dtype 必须提前确定，无法动态 resize；
- 对
.memmap做.sum()、.mean()等聚合操作时，底层仍是分块读取，不会全载入——这点和普通 ndarray 本质不同。
df.groupby().apply() 的 peak 内存可能出现在 apply 函数内部，而不是 groupby 本身。所以最省事的起点，永远是先用 memory_profiler 跑一遍，盯着 Line # 那列找尖峰，再针对性切。 
