Pandas 2.0中Arrow后端默认关闭且仅部分生效，需显式启用：read_csv须指定engine="pyarrow"并推荐dtype_backend="pyarrow"，read_parquet默认已用Arrow但复杂结构需调参。
Arrow后端在Pandas 2.0中默认不可用
Pandas 2.0确实引入了对Arrow后端的实验性支持，但pd.options.mode.use_pyarrow默认为False，且Arrow后端仅影响部分IO操作（如read_parquet、read_csv中的某些参数），不自动接管所有DataFrame运算。想靠开个开关就提速，行不通。
常见错误是直接设置pd.options.mode.use_pyarrow = True后读CSV，结果性能没变化甚至变慢——因为read_csv默认仍走C引擎，Arrow支持需显式启用。
- 必须安装
pyarrow（≥12.0，Pandas 2.0要求）：pip install pyarrow>=12.0 -
read_csv需传engine="pyarrow"，不能只靠全局选项 -
read_parquet默认已用Arrow，但若文件含嵌套结构或字典编码，仍需检查use_threads和dtype_backend
read_csv用PyArrow引擎的实际写法
PyArrow引擎对大文本文件（尤其列类型明确、无复杂解析逻辑的场景）有明显优势，但行为与默认C引擎不同：它不自动推断bool或category，缺失值统一为pd.NA而非np.nan，且不支持skiprows或converters等参数。
典型提速写法：
立即学习“Python免费学习笔记（深入）”；
import pandas as pd
df = pd.read_csv("data.csv", engine="pyarrow", dtype_backend="pyarrow")
-
dtype_backend="pyarrow"让列使用Arrow原生类型（如string[pyarrow]），避免转成Python对象；省略此项则fallback为NumPy类型 - 若列名含空格或特殊字符，PyArrow引擎可能报
ArrowInvalid，需先清理列名或加names=... - 内存占用通常更低，但首次导入
pyarrow会多耗约50–100ms，小文件（
Parquet读取时Arrow后端的隐藏开销
read_parquet在Pandas 2.0中默认使用Arrow，但性能瓶颈常不在解码本身，而在后续转换——比如你读完立刻调df["col"].str.contains(...)，Pandas会把string[pyarrow]列临时转成Python字符串列表，触发大量内存拷贝。
- 保持列在Arrow backend下运算：用
df["col"].str.pyarrow.contains(...)（返回ArrowStringArray） - 避免混合backend操作：不要把
string[pyarrow]和object类型列一起做concat，会强制降级 -
use_threads=True（默认）对多核有效，但若文件分块极小（
Python 3.12 + Pandas 2.0的ABI兼容陷阱
PyArrow 12+已支持Python 3.12，但部分Linux发行版的预编译wheel可能未及时更新。若import pyarrow失败或read_csv(..., engine="pyarrow")抛ImportError: cannot import name 'ArrowEngine'，大概率是PyArrow版本不匹配。
- 优先用
pip install --upgrade "pyarrow>=12.0.1"（12.0.1起正式支持3.12） - conda用户注意channel：
conda install -c conda-forge pyarrow=12.0.1比defaults更可靠 - 若用
poetry，确认pyproject.toml中pyarrow版本锁定明确，避免依赖冲突导致Pandas回退到fallback引擎
真正决定性能的不是“用了Arrow”，而是数据路径上每一步是否维持Arrow类型链路——从读取、过滤到输出，中间任何一次隐式转换都可能吃掉一半提速收益。
