pyarrow 成为 pandas 2.x 默认内存后端，即字符串、整数等统一由 arrow 连续内存块+空值位图管理，替代 pandas 1.5 的 object dtype 和混用 nan/none；需显式设 dtype_backend='pyarrow' 或 dtype='string[pyarrow]' 才生效，否则仍回退至 numpy 表示。
PyArrow 成为 Pandas 2.x 默认内存后端，不是可选插件
本质区别就一句话：pandas 2.x 把 PyArrow 从“能用”升级为“默认启用的底层数据表示”，而 pandas 1.5 仍以 NumPy 数组为核心。这不是加了个新参数的事——是整个数据在内存里怎么存、怎么算、怎么传的根本性切换。
在 pandas 1.5 中，字符串列默认是 object dtype，每个字符串都是独立 Python 对象，指针散落在堆内存各处；缺失值处理靠 NaN、None、pd.NA 混用，类型系统割裂。而 pandas 2.x 启用 Arrow 后，字符串、整数、时间戳等都统一由 Arrow 的连续内存块 + 独立空值位图（null bitmap）管理，天然支持零拷贝和 SIMD 加速。
你不需要手动“切换引擎”才能受益——只要装的是 pandas>=2.0.0 且环境中有 pyarrow，很多操作（如 read_csv、Series(dtype='string')）已默认走 Arrow 路径。但注意：engine='pyarrow' 是显式指定解析器，dtype_backend='pyarrow' 才是控制内存表示方式，二者常被混淆。
字符串列内存占用暴跌 50%–80%，关键看 dtype 定义方式
这是最直观、最容易验证的性能提升点。同一份百万行字符串数据，在 pandas 1.5 下用 object 类型占 200MB，在 pandas 2.x 下用 string[pyarrow] 可能只占 40MB。
- 错误做法：直接
df['col'] = df['col'].astype('string')—— 这会回退到StringDtype（基于 NumPy 的 nullable 字符串），内存节省有限 - 正确做法：显式声明
dtype={'col': 'string[pyarrow]'}或全局设置pd.options.mode.dtype_backend = 'pyarrow' - 读 CSV 时一步到位：
pd.read_csv('data.csv', dtype_backend='pyarrow')，比先读再转 dtype 更省内存
别依赖 infer_objects() 或自动推断——Pandas 2.x 默认推断仍是 object，必须主动指定或配置后端。
read_csv 性能翻倍甚至更快，engine 和 dtype_backend 要配对用
engine='pyarrow' 控制 CSV 解析阶段是否用 PyArrow 解析器；dtype_backend='pyarrow' 控制解析完的数据存在哪。两者不配对，就只吃到一半红利。
- 仅设
engine='pyarrow'：解析快，但结果仍是object字符串 +float64数值，内存没降 - 仅设
dtype_backend='pyarrow'：解析仍走 Python/C 逻辑，慢，但后续计算和内存表现好 - 两者都设：
pd.read_csv('x.csv', engine='pyarrow', dtype_backend='pyarrow')—— 解析快 + 存储省 + 后续算得快
实测中，3GB CSV 文件在 M2 Mac 上：纯 NumPy 方式耗时 58 秒、峰值内存 7.9GB；双 PyArrow 配置下仅 9.2 秒、峰值内存 2.6GB。差距不是线性，是数量级的。
groupby 和缺失值运算提速，但要注意 NA 语义变化
pandas 2.x 重写了部分 groupby 内核，尤其在字符串分组、含大量 NA 的数值聚合上明显快于 1.5。但提速的前提是你用的是 Arrow-backed 类型，比如 int64[pyarrow] 或 string[pyarrow]。
NA 处理逻辑也变了：int64[pyarrow] 列允许原生存整数 + pd.NA，不会像 pandas 1.5 那样自动转成 float64；但这也意味着 np.nan == np.nan 这类旧习惯在 Arrow 类型下不成立——pd.NA == pd.NA 返回 pd.NA，不是 True 或 False。
容易踩的坑：
- 用
.fillna(0)处理int64[pyarrow]列时，若未指定downcast，可能得到int64结果而非保持[pyarrow]后缀 - 与旧代码混用时，
df.dtypes显示string[pyarrow]，但某些第三方库（如旧版plotly）可能不识别该类型，需临时转成str -
pd.concat([df1, df2])若两个 DataFrame 的同名列一个用string、一个用string[pyarrow]，结果会降级为object，白丢性能
最复杂的地方不在“怎么开开关”，而在“类型一致性”——一旦启用 PyArrow 后端，就得全程守住它，否则性能收益会在链式操作中悄悄蒸发。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
