dtype_backend="pyarrow"默认不省内存，因为仅设全局选项不强制IO函数生效；未在read_csv()等中显式传参会导致仍生成object列，且混合类型、未转Int64[pyarrow]等会回退至高开销表示，全程需避免任何object中间态。
PyArrow后端在Pandas 2.0中确实能显著降低内存占用，但前提是正确启用且数据类型适配得当——直接设置pd.options.mode.dtype_backend = "pyarrow"只是第一步，不处理字符串/缺失值的底层表示，内存反而可能上涨。
为什么dtype_backend="pyarrow"默认不省内存？
PyArrow后端启用后，object列（尤其是含混合类型或大量None的字符串列）会转为string[pyarrow]，但若原始数据含Python对象（如字典、自定义类）、或未显式指定nullable整数类型，Pandas仍会回退到Python对象数组，失去内存优势。
- 字符串列必须不含嵌套Python对象，否则
string[pyarrow]构建失败，自动降级为object -
int64列含NaN时，不显式转为Int64[pyarrow]，仍用float64模拟缺失，浪费内存 - 读取CSV时未传
dtype_backend="pyarrow"，即使全局设了选项，read_csv()也不会自动应用
读取阶段就锁定PyArrow类型
在read_csv()、read_parquet()等IO函数中显式传参，比依赖全局选项更可靠，也避免中间产生临时object列。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- CSV：用
pd.read_csv("data.csv", dtype_backend="pyarrow")，同时建议加low_memory=False防止块间类型不一致导致回退 - Parquet：原生支持PyArrow，但需确保写入时也用PyArrow引擎：
df.to_parquet("out.parquet", engine="pyarrow") - 对已存在的DataFrame，用
df.convert_dtypes(dtype_backend="pyarrow")比astype()更安全，它会智能选择string[pyarrow]、boolean[pyarrow]等
警惕string[pyarrow]的隐式拷贝陷阱
PyArrow字符串列看似节省内存，但在调用.str方法（如.str.upper()）或参与merge()时，若涉及编码转换或字节偏移重排，PyArrow可能触发完整数据拷贝，瞬时内存翻倍。
立即学习“Python免费学习笔记（深入）”；
- 避免链式
.str操作，先用.str.extract()或.str.replace()拿到结果再处理 -
merge()前确认左右表key列都是string[pyarrow]且编码一致（如都为UTF-8），否则自动转object - 用
df.memory_usage(deep=True)定期检查，特别关注string[pyarrow]列的memory_usage是否异常高于预期
PyArrow后端真正的省内存收益，藏在“从磁盘加载→类型推断→计算链路”全程不出现object列。一旦某步被迫转成object，后续所有优化都会失效——这比参数没设对更难排查。
