开启CoW后，df.iloc[:, :3]不占内存是因为始终返回逻辑视图且延迟复制；仅当修改时才分离并复制对应列的数组。
开启 pd.options.mode.copy_on_write = True 后，Pandas 2.0 不再为每次切片、筛选或列提取都立即分配新内存，而是延迟到真正写入时才复制——这直接让中间变量激增的清洗流程内存压力骤降，且避免了大量隐式深拷贝带来的 CPU 开销。
为什么 df.iloc[:, :3] 这类操作突然不占内存了？
旧版中，df.iloc[:, :3] 可能返回视图（共享底层数组）或副本（新分配内存），行为不可控；启用 CoW 后，它**总是返回逻辑视图，但底层不复制数据缓冲区**——只要你不修改，多个子集变量共用同一块内存。
- 适用场景：ETL 中频繁切片+拼接（如
pd.concat([df.iloc[:, :2], df.iloc[:, 5:7]])），CoW 下 concat 不触发数据复制，只重组元数据 - 注意点：若子集后续被修改（如
sub.loc[0, 'a'] = 99），此时才分离并复制对应列的 ArrowArray 或 NumPy 数组 - 性能影响：百万行 DataFrame 切片 10 次，在 PyArrow + CoW 组合下内存增长几乎为 0；旧版可能多占 800MB+（object dtype 字符串列尤为明显）
df['col'] = value 和 df.loc[:, 'col'] = value 的行为差异变关键了
CoW 彻底拆开了这两者的语义：df['col'] = value 永远新建列对象（不复用原数组），而 df.loc[:, 'col'] = value 才尝试就地写入——若检测到共享（如 s = df['col'] 后再执行此句），则触发复制，s 不变，df['col'] 获得新数组。
- 容易踩的坑：把
df[df.a > 0]['b'] = 1当链式赋值用 → 现在直接静默失败（或报SettingWithCopyWarning），必须改用df.loc[df.a > 0, 'b'] = 1 - 为什么重要：旧版中这类写入有时生效、有时不生效，调试成本高；CoW 下行为 100% 可预测，且避免了“以为改了结果没改”的逻辑漏洞
- 参数差异：仅当列是 PyArrow dtype（如
string[pyarrow]）时，.loc写入才能真正零拷贝；NumPy dtype 下仍需复制整列
不装 pyarrow 却开 CoW？运行时大概率报错
CoW 在涉及字符串、缺失值（pd.NA）、整数空值列时，严重依赖 PyArrow 的底层实现。没装 pyarrow 库却设了 copy_on_write = True，代码很可能在第一次调用 df['text'].str.upper() 或 df.fillna() 时崩出 AttributeError: 'StringArray' object has no attribute '_mgr'。
立即学习“Python免费学习笔记（深入）”；
- 正确做法：先
pip install pyarrow，再全局配置pd.options.mode.dtype_backend = "pyarrow"，最后开 CoW - 兼容性影响：PyArrow dtype 默认启用 CoW，即使用
df = pd.DataFrame({"x": [1, 2]}, dtype="int64[pyarrow]")，无需显式设选项，切片和写入也自动延迟复制 - 别混淆：
engine='pyarrow'（仅加速read_csv解析）≠dtype_backend='pyarrow'（决定内存布局），后者才是 CoW 发挥作用的基础
最易被忽略的一点：CoW 的性能收益不是均匀分布的——它对“读多写少、中间步骤多”的清洗流水线提升极大，但对单次聚合（如 df.groupby('key').sum()）几乎无影响；如果你的瓶颈在计算而非内存搬运，该调 Numba 引擎或换 dtype，而不是只盯 CoW。
