pd.read_csv()默认慢是因为C引擎逐行解析、动态推断类型并频繁构造Python对象，导致CPU和GC压力大；启用PyArrow后端需显式指定engine="pyarrow"、预设dtype和usecols，才能实现3–6倍提速与内存减半。
pd.read_csv() 默认不快，是因为它用 c 引擎逐行解析、动态推断类型、频繁构造 Python 对象——尤其遇到混合类型列或缺失值时，CPU 和 GC 压力陡增。这不是“等一会儿就好”的问题，是底层执行模型决定的瓶颈。Pandas 2.0 的价值，不在语法变化，而在它让 PyArrow 后端真正可落地：**只要参数写对，3–6 倍提速、内存压降一半以上，且不改业务逻辑**。
engine="pyarrow" 必须显式传，否则根本不用
装了 pyarrow>=12.0.0 并不能自动启用加速；pd.read_csv("x.csv") 永远走默认 c 引擎。必须显式加 engine="pyarrow"，否则静默 fallback，连警告都不抛。
-
pip install "pandas>=2.0.0" "pyarrow>=12.0.0"—— 版本低一丁点（比如pyarrow==11.0.0）就退回到 Python 引擎 -
pd.read_csv("data.csv", engine="pyarrow")—— 少一个参数，就等于没换后端 -
dtype_backend="pyarrow"是全局设置，但只影响新创建对象的默认 dtype，不改变read_csv的引擎选择
dtype 和 usecols 不是“可选优化”，而是 PyArrow 的硬性前提
PyArrow 不做“先读几行猜类型再重读”，它按 schema 流式解析。漏写 dtype，它照样走慢路径；不声明 usecols，它仍会加载全部列再丢弃——浪费 I/O 和内存。
- 字符串列含大量重复值？必须写
dtype={"col": "category"}，不能只靠astype("category")后处理 - 日期列要解析？用
parse_dates=["col"]或dtype={"col": "date32[day][pyarrow]"}，否则遇到非法格式直接抛ArrowInvalid: Unable to parse string - 列名含空格或特殊字符？
usecols必须传原始字符串列表，如["user id", "price $"]，不能指望names重命名后再选
low_memory=False 和 skipfooter 这类参数容易误用
low_memory=False 在 PyArrow 下完全无效，但它不报错，留着也不影响——但别误以为它能“辅助提速”。skipfooter 则更危险：PyArrow 不支持，会静默忽略，导致你以为跳过了最后 N 行，实际全读进来了。
-
skiprows和nrows支持，可用于分块采样或调试 -
chunksize仍可用，但注意 PyArrow 返回的是TextFileReader，每块仍是 Arrow-backed DataFrame，不是传统 object-dtype -
pd.read_excel()完全不支持engine="pyarrow"，Excel 大文件提速得另找方案（比如先转 CSV 或用openpyxl+polars）
特征工程中真正省时间的不是“算得快”，而是“读得准、载得稳”
大规模特征工程卡点常不在 groupby().agg()，而在第一步——读进来就崩、类型错乱、内存爆掉。PyArrow 后端的价值，是把这种不确定性收束到明确的参数契约里：engine、dtype、usecols 三者缺一不可。一旦写对，后续所有向量化操作（str.contains()、cut()、get_dummies()）天然受益于 Arrow 的列式内存布局和零拷贝特性。
立即学习“Python免费学习笔记（深入）”；
最容易被忽略的，是日期列和 category 列的 dtype 声明方式：必须用字符串（如 "category"），不能传 CategoricalDtype；必须用 Arrow-aware 类型字符串（如 "date32[day][pyarrow]"），不能套用旧版 NumPy 写法。写错一个，整个列就回退到 object 模式，速度优势归零。
