Pandas 2.0的Arrow后端提速核心在于dtype_backend="pyarrow"启用Arrow内存布局，而非仅engine="pyarrow"加速解析；前者实现连续内存+位图结构，显著降低内存占用并加速后续操作。
因为Pandas 2.0的Arrow后端不是“单纯换了解析器”，而是把整个数据落地路径从NumPy对象堆管理，切换成了PyArrow的连续内存块+位图结构——解析快只是表象，真正提速来自后续所有操作都省去了类型推断、对象遍历和隐式拷贝。
read_csv()里engine="pyarrow"只加速解析，不改内存布局
很多人以为装了pyarrow、加了engine="pyarrow"就自动省内存又提速，其实这只是让CSV解析阶段用C++实现的PyArrow parser跑一遍，快是快了，但解析完若没配dtype_backend="pyarrow"，字符串列大概率还是object dtype，后续.str.contains()或.groupby()照样慢。
-
engine="pyarrow"仅影响解析器选择，对Parquet文件默认已生效（只要pyarrow装了） -
engine="python"或engine="c"会覆盖engine="pyarrow"设置，别混用 - CSV中
parse_dates、na_values等参数在PyArrow引擎下大多失效，日期得读完再.astype("timestamp[ns][pyarrow]")
dtype_backend="pyarrow"才是内存和性能拐点
这个选项决定了DataFrame创建后，字符串、整数、布尔列实际存在哪儿：启用后，默认走Arrow内存布局——连续字节数组+独立null bitmap，而不是每个字符串一个Python对象。实测100万行城市名，object占260 MB，string[pyarrow]只占45 MB。
- 必须全局设：
pd.options.mode.dtype_backend = "pyarrow"，或单次调用传dtype_backend="pyarrow" -
df["col"].astype("string")≠string[pyarrow]，前者仍是基于NumPy的StringDtype，内存几乎不降 - 混合类型列（如数字里夹几个"N/A"）会被推断为
string[pyarrow]而非报错，这是Arrow更激进但更一致的类型策略
Parquet读取时PyArrow引擎开箱即用但有隐性陷阱
pd.read_parquet()在Pandas 2.0中只要装了pyarrow，默认就走PyArrow逻辑，不用显式写engine="pyarrow"。但它对分区路径和schema敏感，稍有不匹配就会退化成低效回退路径，甚至OOM。
立即学习“Python免费学习笔记（深入）”；
- 分区列名大小写、路径斜杠结尾、schema中timestamp时区信息缺失，都可能导致列裁剪失效、全量加载
- 谓词下推（
filters参数）只在PyArrow原生支持的格式（如snappy/zstd压缩）下有效，fastparquet后端不支持 - CPU缓存友好性来自Arrow的列式连续布局，不是单纯多线程——所以即使
n_threads=1，单核吞吐也常高于NumPy版
最易被忽略的是：PyArrow后端不是“装了就生效”，它需要你主动在读取时指定engine，并在数据落地后靠dtype_backend锁定内存表示；两个开关缺一不可，否则你看到的只是解析变快了32倍，而后续清洗仍卡在object列上。
