MemoryError 是因数据过载内存所致，非 Pandas Bug；应通过 chunksize 分块读取、优化数据类型、避免隐式膨胀操作及清理残留引用等方式控制内存驻留量。
直接说结论：MemoryError 不是 Pandas 有 bug，而是你一次性让太多数据进了内存——哪怕只多载入几 MB，它就崩。关键不是“换库”，而是控制每一步的内存驻留量。
用 chunksize 分块读取 CSV，别碰全量 read_csv()
这是最常被跳过的一步。很多人设了 chunksize=10000，但还在外面写 df = pd.read_csv('big.csv')，等于完全没用。
- 必须把
chunksize当作读取逻辑的一部分，而不是后期优化开关 - 每次迭代中，
chunk是独立 DataFrame，上一块处理完后立刻丢弃（不 append 到大 list 里存着） - 如果要做全局统计（比如总和、均值），用累加器变量代替拼接：
total_sum += chunk['col'].sum()，而不是chunks.append(chunk) - 注意：
chunksize不是越大越好。8GB 内存机器建议从 5000–20000 行起步，配合memory_usage='deep'实测峰值
改掉默认 object 和 float64，类型不对等于白省
一个含百万行、50 列字符串的 object 列，实际内存可能比整张表还高——因为每个字符串单独分配堆内存，且无共享引用。
- 重复值多的字符串列（如状态、地区、分类）→ 强制转
category：df['status'] = df['status'].astype('category') - 整数列看取值范围：
0–255用uint8，-32768–32767用int16，别死守int64 -
datetime列务必指定parse_dates+infer_datetime_format=True，否则会退化成object - 检查手段：
df.info(memory_usage='deep')，重点关注memory usage行，不是dtypes表面信息
避免 .T、.groupby().apply()、.pivot() 这类隐式膨胀操作
这些方法本身不报错，但内部会构建临时结构——out.T 可能瞬间申请和原 DataFrame 等大的新内存，groupby().apply(lambda x: x * 2) 会为每组复制一份子 DataFrame。
立即学习“Python免费学习笔记（深入）”；
- 替代
.T.groupby().sum().T：改用df.groupby(...).sum(numeric_only=True)，跳过转置 - 避免
.apply()在大表上逐行调用函数；优先用向量化操作或.agg() - 不用
.pivot()做宽表展开，改用pd.crosstab()或分块pd.get_dummies()+sparse=True - 警惕
.copy()和.values：后者强制转ndarray，稀疏结构瞬间变稠密
别信 IDE 自动补全，关掉 Jupyter 的 autoreload 和变量历史缓存
很多人在 VS Code 或 Jupyter 里反复运行同一段代码，以为只是重跑，其实 df 变量一直挂在内核里，gc.collect() 也清不干净——尤其用了 %store 或 IPython.cache。
- Jupyter 中执行
%reset -f清空全部命名空间，比del df可靠得多 - VS Code 的 Python 扩展默认启用变量监视器，对 >10 万行 DataFrame 会偷偷做摘要计算，关掉设置项：
python.dataScience.variableExplorerExclude - PyCharm 用户注意：
Settings > Tools > Python Console > Use IPython关闭，否则历史变量全驻留 - 真正危险的是你以为“删了就没了”，但
plt.plot(df.x, df.y)后 matplotlib 仍持有引用，得显式plt.close('all')
最易被忽略的一点：内存问题往往不出现在你写的主逻辑里，而出现在日志打印、异常 traceback、甚至 df.head() 的预览触发中——它们会强制加载索引、计算长度、生成 HTML 表格。处理前先关掉所有自动展示，用 len(df) 和 df.dtypes 替代 df.info()。
