pandas字符串列用object类型致内存暴增5–10倍，因每字符串为独立Python对象（48字节开销）；应转category、用string dtype、显式指定dtype/usecols/parse_dates、优化merge/groupby、合理使用chunksize。
object类型字符串列吃掉5–10倍内存
pandas 默认把字符串列存为 object 类型，每个值都是一个独立的 Python 对象指针，附带 48 字节开销。100 万行、平均长度 20 字符的字符串列，磁盘上约 20MB，加载进内存后轻松突破 200MB。这不是 bug，是设计使然——pandas 为兼容任意 Python 对象牺牲了紧凑性。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 低基数文本（如状态码、国家名、分类标签）立刻转
category：df['status'] = df['status'].astype('category') - 高基数但只用于过滤/匹配的列，可先
usecols跳过，或用dtype={'col': 'string'}（Pandas 2.0+）启用更省内存的字符串实现 - 别信“我数据不大”，用
df.memory_usage(deep=True).sum()实测每列真实占用，object列通常占总内存 60% 以上
pd.read_csv() 默认全量加载 + 二次类型推断
调用 pd.read_csv('big.csv') 时，pandas 不仅把全部内容读进内存，还会扫描一遍数据猜 dtype，再扫描一遍做转换。50GB 文件光推断就可能卡住几小时，且中间生成多个临时副本。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 永远显式传
dtype：数值列用'int32'/'float32'，分类列用'category'，整数 ID 可考虑'uint32' -
usecols必加：哪怕只用 3 列，也写usecols=['id', 'ts', 'value']，跳过解析其余 297 列 - 日期列别等自动识别，直接传
parse_dates=['ts']和date_parser=...避免字符串缓存
merge / groupby / apply 触发隐式拷贝与笛卡尔膨胀
pd.merge() 不是“按 key 对齐”那么简单——它会为左右表重建索引、对齐 NaN、生成中间 join 表，内存峰值常达两表原始内存之和的 2–4 倍。更危险的是 apply()：每行调一次 Python 函数，触发 GIL + 对象构造，千万行就是千万次开销。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 合并前先
left.set_index('key', drop=False)、right.set_index('key')，避免 merge 内部重复建索引 - 避免
df.apply(..., axis=1)，改用向量化（df.eval()、np.where）或groupby().agg() - 大表 merge？别硬刚：导出到 SQLite 用 SQL JOIN，或用
dask.dataframe（注意启动开销，小数据反而更慢） - merge 后立刻
del left, right，Windows 下建议跟一句import gc; gc.collect()
chunksize 不是开关，是操作范式
chunksize=10000 返回的是 TextFileReader 迭代器，不是 DataFrame。常见错误是把它当列表用：list(reader) 或 pd.concat([c for c in reader]) ——这等于又把全量数据加载进内存。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- chunk 处理完必须丢引用：
del chunk；循环里别用chunks.append(chunk) - 流式写入优先：
chunk.to_csv('out.csv', mode='a', header=first)或chunk.to_sql(..., if_exists='append') - chunksize 值要实测：先
pd.read_csv(f, nrows=5000)算内存，再按目标内存反推合理行数，别抄别人参数 - 想预览首块又不破坏迭代？用
first = next(pd.read_csv(f, chunksize=5000))，别用reader.get_chunk()
category、数值列没压成 int32、merge 前没设 index 时，内存占用会以非线性方式爆炸。这些点不手动干预，光靠升级硬件或换库解决不了根本问题。 
