memoryerror通常发生在python尝试分配连续内存块失败时，如list(range(10**9))或一次性读取大csv到dataframe中，表明虚拟内存已耗尽，需改用生成器、流式处理、分块迭代等预防性策略。
MemoryError 出现在什么场景下
不是所有大数组或大数据都会立刻触发 MemoryError，它通常发生在 Python 尝试分配连续内存块失败时——比如用 list(range(10**9)) 构造十亿个整数，或一次性读取几个 GB 的 CSV 到 pandas.DataFrame 中。这时候系统没报“磁盘满”或“权限拒绝”，而是直接抛出 MemoryError，说明进程的虚拟内存（或物理内存+swap）已无法满足当前分配请求。
关键点：这不是代码逻辑错误，而是资源边界被触达。你没法靠“改写 for 循环”绕过去，得换数据处理范式。
别 try-except 捕获 MemoryError 做兜底
很多人第一反应是加 try...except MemoryError: 然后降级处理。这几乎没用：
-
MemoryError发生时，Python 解释器往往已处于内存极度紧张状态，再执行 except 块里的任何对象创建（比如日志字符串、新列表）都可能再次触发异常 - 它不保证可恢复：即使捕获成功，堆内存碎片化严重，后续操作仍大概率失败
- 它掩盖了根本问题：你本该在分配前预估/限制，而不是等崩溃后补救
真正该做的是预防——提前知道你要什么、有多大、能不能放得下。
用生成器和流式处理替代全量加载
绝大多数 MemoryError 都源于“一次性全量加载”。对应解法非常明确：把 list 换成 generator，把 read() 换成 readline() 或分块迭代。
常见替换示例：
# ❌ 危险：全量读入内存
with open("huge.log") as f:
lines = f.readlines() # 可能爆内存
<h1>✅ 安全：逐行迭代（文件对象本身就是迭代器）</h1><p>with open("huge.log") as f:
for line in f: # 不会一次性加载全部
process(line)</p><h1>❌ pandas 全量读 CSV</h1><p>df = pd.read_csv("5GB_data.csv")</p><h1>✅ 分块读 + 处理</h1><p>for chunk in pd.read_csv("5GB_data.csv", chunksize=10000):
result = chunk.groupby("category").sum()</p><h1>累加到外部变量，或写入数据库/文件，不保留全部 chunk</h1><p></p>
注意：chunksize 不是越大越好——要结合单块处理耗时与内存余量权衡；range(10**9) 必须换成 range 对象（它本身是生成器），而非 list(range(...))。
检查并降低对象引用开销
有时你以为只存了一组数字，其实 Python 在背后悄悄占了更多内存。比如：
-
list存整数，每个元素是int对象指针（64 位系统约 8 字节），外加对象头、引用计数等，实际一个int可能占 28 字节以上 - 用
numpy.array替代list存数值数据，内存占用常能降到 1/10；array.array('i')（C 风格数组）比纯 Python list 更轻量 - 避免无意中保留大对象引用：比如函数内生成大数组后，忘记
del big_array，或把它意外塞进全局缓存里
验证手段：用 sys.getsizeof() 粗略看对象自身内存，配合 gc.get_objects() 找可疑大对象；更准的用 pympler.asizeof()。
真实复杂点在于：很多库（如 scikit-learn 的某些拟合器）内部会缓存训练数据副本。这时光改输入没用，得查文档看有没有 copy_X=False 这类参数开关。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
