pandas 2.0 内存优化核心在于默认启用 PyArrow 后端（需配置 dtype_backend='pyarrow'）和写入时复制（CoW），字符串等列转为连续内存+空值位图，避免 object dtype 开销，且 CoW 延迟拷贝降低中间变量内存压力。
pandas 2.0 在内存管理上比 1.x 更优秀，核心原因不是“加了新功能”，而是默认用 pyarrow 替代了 numpy 作为底层数据表示方式。这直接改变了字符串、整数、时间戳等列在内存里怎么存、怎么标记缺失值、怎么共享或拷贝。
字符串列不再用 object dtype 散落堆内存
在 pandas 1.5 中，字符串列默认是 object dtype：每个字符串都是独立的 Python 对象，指针随机分布在堆内存中，无法 SIMD 加速，GC 压力大，且空值混用 None/np.nan/pd.NA。
而 pandas 2.0 启用 pyarrow 后端（需显式配置），字符串统一存为连续内存块 + 独立空值位图（null bitmap）：
-
dtype='string[pyarrow]'下百万行字符串可能只占 40MB，而非 200MB+ - 没有 Python 对象头开销，零拷贝序列化/传输更自然
-
pd.isna()不再触发类型推断或对象遍历，直接查位图
dtype_backend='pyarrow' 才控制内存表示，不是 engine='pyarrow'
这两个参数常被混淆，但作用完全不同：
立即学习“Python免费学习笔记（深入）”；
-
engine='pyarrow'只影响read_csv()解析阶段是否用 PyArrow C++ 解析器——快，但解析完仍可能回退到 NumPy 表示 -
dtype_backend='pyarrow'才真正决定解析后的数据存在哪：启用后，string、integer、boolean等列默认走 Arrow 内存布局 - 必须两者配对：
pd.read_csv(..., engine='pyarrow', dtype_backend='pyarrow')才能吃到完整红利 - 只设
engine不设dtype_backend，字符串列大概率仍是object，内存省不了
写入时复制（Copy-on-Write）让链式操作不爆内存
pandas 2.0 默认开启写入时复制（CoW），这是内存管理的第二层保障：
- 执行
df2 = df1.dropna()或df2['x'] = df1['y'] * 2时，不立即拷贝底层数据，只建引用 - 直到你调用
df2.loc[0, 'x'] = 999这类修改操作，才真正分离内存块 - 这对临时中间变量多、分步清洗的场景极友好；老版本中
df.copy()隐式触发频繁深拷贝，容易触发 OOM - 注意：CoW 默认启用，但某些就地操作（如
inplace=True）可能绕过它，建议少用inplace
最关键的一点容易被忽略：pandas 2.0 的 PyArrow 支持不是“可选插件”，而是“默认启用路径”，但必须满足两个前提——装了 pyarrow 包，且主动配置 dtype_backend 或列级 dtype。不配置，它就安静地退回 numpy 模式，连内存节省的影子都看不到。
