用 chunksize 分块读取是最常用且可控的超大 csv 内存优化方式，但需配合手动迭代、及时释放引用及 dtype 优化，避免累积 chunk 导致内存溢出。
直接结论：用 pandas.read_csv() 的 chunksize 参数分块读取，是处理超大 CSV 导致内存溢出最常用、最可控的方式；但必须配合手动迭代和及时释放引用，否则 chunk 本身累积仍会爆内存。
为什么 chunksize 不等于自动省内存
很多人设了 chunksize=10000 就以为万事大吉，结果跑着跑着还是 MemoryError。根本原因是：pandas 默认把每个 chunk 当作独立 DataFrame 存在，如果你用 list.append() 全部存下来，或者在循环里不断做 pd.concat()，内存只会线性增长。
- chunk 是 DataFrame 对象，不是轻量指针 —— 每个 chunk 占用实际内存
- Python 的垃圾回收不保证立刻释放，尤其当变量名还被局部作用域持有时
- 字符串列、类别型列、重复索引都会显著放大单个 chunk 的内存开销
正确使用 chunksize 的实操要点
核心原则：每个 chunk 处理完就丢掉，不累积，不拼接（除非真需要全量）。
- 用
for chunk in pd.read_csv(..., chunksize=N)迭代，不要转成 list 或 dict - 对每个 chunk 做「就地处理」：比如过滤后立即写入新文件、聚合统计后只保留标量、或调用
chunk.to_sql()流式入库 - 显式删除 chunk 引用：
del chunk，再调用gc.collect()（小概率需要，但大文件下建议加） - 注意
dtype预设：不指定时 pandas 会推断为object或高精度数值，改用dtype={'col': 'category'}或'float32'可降 30%~70% 内存
常见错误现象与对应修复
这些报错背后往往不是文件太大，而是 chunk 使用方式错了：
-
MemoryError出现在第 5 个 chunk 之后 → 很可能你做了all_chunks.append(chunk)，立刻改成流式处理 -
ValueError: cannot concatenate a non-NDFrame object→ 误把TextFileReader当 DataFrame 用了，记得它是可迭代对象，不是 DataFrame - 内存占用稳定在 2GB 但 CPU 100% 卡住 → chunksize 太小（如设成 100），I/O 和 Python 解析开销反超收益，建议从 5000–50000 试起，观察内存/时间平衡点
- 读取后发现某列全是
NaN→ 某些 chunk 中该列为空，pandas 推断 dtype 失败，统一加dtype={...}或keep_default_na=False+ 手动na_values
替代方案什么时候该考虑
chunksize 不是银弹。以下情况建议换路子：
- 只需要读几列：用
usecols+chunksize，避免加载无关字段 - 行数超 10 亿、且只需聚合（sum/count/mean）：用
dask.dataframe.read_csv()或纯 Python 的csv.DictReader+ 逐行累加，内存更稳 - 有复杂解析逻辑（正则提取、嵌套 JSON 字段）：先用
chunksize读原始字符串，再用io.StringIO二次解析，避免 pandas 自动类型转换吃内存 - 需随机访问某几行：
chunksize不适用，改用linecache.getline()或建立行号索引文件
真正难的不是设 chunksize，而是想清楚「这一步到底要产出什么」—— 是一个数字？一行记录？还是一张新表？目标模糊，chunk 就容易变成临时缓存，而不是处理管道中的一环。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
