PyArrow后端不自动省内存，需配合流式读取、显式dtype和字典编码判断：整列加载仍致OOM；数值列numpy_nullable更省30%+内存，高重复字符串列PyArrow字典编码更优。
PyArrow后端开启后仍报MemoryError或OOM崩溃
开PyArrow后端不等于自动省内存——它只是把底层数据存储换成了Arrow格式，但Pandas默认仍会把整列加载进Python对象（如pyarrow.StringArray转成object dtype），反而可能因双重引用加重压力。关键在控制“何时、以何种粒度”读入数据。
- 用
pd.read_parquet()时加use_pandas_metadata=True避免元数据重复解析 - 对大CSV，别直接
pd.read_csv(..., engine="pyarrow")——先用pd.read_csv(..., chunksize=50000, engine="pyarrow")流式处理 - 禁用自动类型推断：
dtype_backend="pyarrow"要配合显式dtype，否则Pandas会在后台悄悄升格为object
为什么dtype_backend="pyarrow"有时比"numpy_nullable"更耗内存
PyArrow backend保留完整Arrow数组结构（含null bitmap、offset buffer等），而"numpy_nullable"只用np.ndarray + 单独的boolean mask。对纯数值列，后者常省30%+内存；但对含大量短字符串的列，PyArrow的字典编码（dictionary encoding）反而更优——前提是数据真有高重复率。
- 检查字符串列是否适合字典编码：
df["col"].nunique() / len(df) - 强制启用字典编码：
pa.array(df["col"], type=pa.dictionary(pa.utf8(), pa.int32())) - 避免混合类型列：PyArrow backend下
objectdtype会退化为pa.large_string()，无压缩且GC压力大
to_parquet()保存时报ArrowInvalid: Unable to convert table schema
这是PyArrow backend下最典型的隐式类型冲突：Pandas把某列识别为string[pyarrow]，但实际含None和bytes混存，Arrow Schema校验失败。错误不是出在写入逻辑，而是上游数据没清洗干净。
- 定位问题列：
df.dtypes[df.dtypes == "string[pyarrow]"] - 统一转纯字符串：
df["col"] = df["col"].astype("string[pyarrow]").str.decode("utf-8", errors="ignore") - 写入时绕过Schema校验（仅调试用）：
df.to_parquet(path, engine="pyarrow", allow_truncated_timestamps=True, use_dictionary=False)
流式处理中chunksize设多大才不爆内存
没有固定值——取决于单行平均字节数和可用RAM。一个可靠估算方式：chunksize ≈ (可用内存 × 0.6) // 单行平均字节数。用df.info(memory_usage="deep")查当前内存占用，再除以行数得均值。
立即学习“Python免费学习笔记（深入）”；
- 实测建议起点：
chunksize=10000（小内存机器）或50000（16GB RAM以上） - PyArrow引擎下，
chunksize影响底层Arrow RecordBatch大小，过大会触发Arrow内部buffer预分配失败 - 别依赖
gc.collect()——PyArrow内存由Arrow内存池管理，需显式调用pa.default_memory_pool().release_unused()
object、category或跨dtype运算，就容易掉回Python对象层。最易被忽略的是读取阶段的隐式转换——哪怕开了dtype_backend="pyarrow"，pd.read_csv()默认仍会把空值列当object处理。 
