PyArrow后端在Pandas 2.0中默认不启用，需显式指定engine="pyarrow"或dtype_backend="pyarrow"才能生效，且CSV读取时参数兼容性差、Parquet支持更稳定，真正优势在于内存节省而非单纯提速。
PyArrow后端在Pandas 2.0中默认不启用，必须显式指定
PyArrow不是Pandas 2.0的默认引擎，即使你已安装pyarrow，pd.read_csv()等函数仍走传统C parser。加速读取的前提是主动切换后端——这一步常被跳过，导致“装了却没用”。
关键操作：在read_csv()、read_parquet()等函数中传入engine="pyarrow"参数（对CSV/JSON）或依赖dtype_backend="pyarrow"（对整表类型统一处理）。
-
read_csv(..., engine="pyarrow")：仅对CSV/TSV生效；注意engine="python"或"c"会覆盖此设置 -
read_parquet(..., engine="pyarrow")：Parquet场景下推荐直接使用，Pandas 2.0已深度集成PyArrow 11+，无需额外配置 -
pd.read_csv(..., dtype_backend="pyarrow")：影响后续列类型推断（如将字符串列转为string[pyarrow]），但不加速解析本身
CSV读取时PyArrow引擎不支持部分常用参数
PyArrow的CSV reader比Pandas原生parser更严格，很多习惯性参数会直接报错或静默失效。典型冲突点集中在缺失值与类型解析上。
常见错误现象：ValueError: unsupported type for column 'x': object 或 TypeError: expected bytes, got str，多因混合类型或空值标记未对齐。
立即学习“Python免费学习笔记（深入）”；
-
na_values和keep_default_na被忽略——PyArrow只认None、空字符串、NULL、NaN字面量，自定义空值需预处理或改用convert_options -
dtype字典中的str、object无效，必须用PyArrow类型如pa.string()或"string[pyarrow]" -
parse_dates不支持——日期列需读入后再用.astype("timestamp[ns][pyarrow]")转换
Parquet读取开箱即用，但分区路径和schema需匹配
PyArrow后端对Parquet的支持最稳定，read_parquet()默认就走PyArrow逻辑（只要PyArrow已安装），无需显式设engine。但实际使用中，路径结构和schema不一致会导致性能骤降甚至失败。
典型问题：读取Hive风格分区目录时，列类型在不同分区文件中不一致（如某分区的user_id是int32，另一分区是int64），PyArrow会拒绝合并。
- 强制统一schema：加参数
use_nullable_dtypes=True+dtype_backend="pyarrow"，让Pandas用Int64[pyarrow]等可空类型兜底 - 跳过schema校验（仅调试用）：
validate_schema=False，但可能引发运行时类型错误 - 避免通配符路径陷阱：
"data/*.parquet"可能漏掉_文件，推荐用dataset接口：pd.read_parquet(pa.dataset(...))
内存占用与列裁剪：PyArrow真正优势不在“快”，而在“省”
很多人期待PyArrow后端大幅缩短读取耗时，实际在小数据集（
例如读取1GB Parquet文件含100列，但只用其中3列——Pandas原生后端仍会解压全部列进内存，而PyArrow可通过columns=["a","b","c"]参数实现真正的列投影（disk → memory直达），内存减少可达70%+
- CSV场景下无列裁剪能力，但
use_threads=True（默认开启）能更好利用多核解析 - 字符串列默认存为
string[pyarrow]，比object节省约40%内存，且支持向量化文本操作（如.str.contains()） - 注意
string[pyarrow]列无法直接传给scikit-learn——需先.to_numpy()或.tolist()，否则报ValueError: Unknown label type
PyArrow后端不是银弹：它对数据格式、缺失值约定、类型一致性更敏感，调得顺时内存和IO效率明显提升，但调试成本略高——尤其当上游ETL输出不规范时，先校验schema比硬切引擎更有效。
