根本原因是pandas.read_csv()默认全量加载+自动类型推断，导致内存占用达原始文件2–3倍；应显式指定usecols、dtype，禁用索引，并用chunksize分块迭代处理且不累积chunk。
根本原因不是文件太大，而是默认加载策略把整份数据塞进内存，且不做类型约束。
pd.read_csv() 默认全量加载 + 自动推断 = 内存翻倍
pandas 读 CSV 不是“边读边解析”，而是先扫描全文件做类型推断（比如某列前 10 行是数字、后 100 行出现空值或字符串，就退化为 object），再一次性分配内存构建完整 DataFrame。一个 10GB 的文本文件，实际内存占用常达 20–30GB——因为 Python 字符串、object 列、重复索引等对象开销远高于原始字节。
- 即使只调用
pd.read_csv("big.csv", nrows=10)，pandas 仍会尝试解析全文件来确保类型一致（除非加low_memory=False或显式dtype） -
infer_datetime_format=True或parse_dates会加重扫描负担，尤其时间格式不统一时 - 未指定
usecols时，哪怕你只用 3 列，pandas 仍为全部 100 列分配内存并解析
chunksize 不等于自动省内存，用错照样 OOM
设了 chunksize=50000 却仍在第 8 块报 MemoryError？大概率是误把 TextFileReader 当成了轻量迭代器——它每次 yield 的是完整 DataFrame，不是指针。
- 错误写法：
chunks = list(pd.read_csv(..., chunksize=50000))→ 所有 chunk 全驻内存 - 错误写法：
all_dfs.append(chunk)然后pd.concat(all_dfs)→ 内存线性增长 - 正确姿势：用
for chunk in pd.read_csv(..., chunksize=50000)，处理完立刻丢弃（del chunk），必要时加gc.collect() - chunksize 太小（如 100）会导致 I/O 和解析开销反超收益；太大（如 50 万行含长文本）单块就爆——建议从 5000–50000 试起，配合
df.memory_usage(deep=True)观察单块内存
字符串和 object 类型是内存黑洞
CSV 里一列用户评论，平均长度 200 字符，100 万行就占 200MB 原始文本；但 pandas 存成 object 类型后，每字符串额外带引用头、哈希缓存、Unicode 开销，实测内存翻 2–3 倍。
立即学习“Python免费学习笔记（深入）”；
- 能转
category的就转（如状态码、地区名），内存可降 70% - 数字列别留默认
float64，改float32或uint32（确认无负数/溢出） - 避免
na_values=["", "N/A", "NULL"]过多导致类型推断失败退化为object - 长文本列若只需统计长度，用
usecols跳过，或在 chunk 内用chunk["text"].str.len()后立刻丢弃原列
上传解析场景的特殊陷阱
Web 服务中接收用户上传的 CSV 并解析，比本地文件更危险：上传流没缓冲控制、临时文件路径不可控、并发请求叠加内存压力。
- 别用
request.files["file"].read()一次性读进内存——改用流式分块读取（stream=True+ 按行解析生成器） - 上传后不要立刻
pd.read_csv(temp_path)，先用head -n 1000（或 Pythonitertools.islice）抽样看 schema，再定dtype和usecols - 并发处理多个上传时，注意全局变量或类属性意外持有了 chunk 引用（比如
self.cache.append(chunk)），导致 GC 不释放 - 用
memory_profiler在开发环境跑@profile，确认峰值内存是否稳定在 chunk 级别，而非随块数增长
真正关键的不是“能不能读完”，而是“每一块处理完后，内存是否回落到起点”。只要发现内存阶梯式上涨，基本就是引用没清干净或类型没压住——这两点比选什么库（pandas/dask/polars）更决定成败。
