关键在于从创建源头控制数据对象生命周期，分三类：显式构造（新建副本，慎用于大数据）、视图生成（零拷贝切片，优先用于定位）、就地修改（inplace覆写，大幅降内存峰值）。
在海量数据清洗中，内存开销主要来自重复加载、中间副本生成和无效对象驻留。真正能“缩短到极致”的关键，不是盲目删数据，而是从数据对象的创建源头控制生命周期——核心在于三种创建方式的选择差异：显式构造、视图（view）生成、就地修改（inplace）。
显式构造：只在必要时新建完整副本
用 pd.DataFrame(...) 或 df.copy() 显式创建新对象，会分配全新内存空间。这对小样本探索或需保留原始快照的场景合理，但处理GB级数据时极易触发OOM。
- 避免
df = df.drop('col').fillna(0).groupby(...)这类链式调用——每次操作都默认返回新副本，内存占用呈倍数增长 - 若必须构造新结构，优先用
pd.concat([df1, df2], ignore_index=True, copy=False)并设copy=False，复用底层数组（前提是输入未被其他变量引用） - 对超大CSV读取，用
pd.read_csv(..., usecols=..., dtype=...)严格限定列和类型，跳过无用字段并防止object类型自动推断膨胀内存
视图（view）生成：零拷贝的逻辑切片
视图不复制数据，仅保存指向原数组的元信息（如索引偏移、步长）。只要操作不破坏内存连续性（如切片、列选取、布尔索引），Pandas会自动返回视图。
-
df_subset = df[['col_a', 'col_b']]是视图（若原df为连续内存），df.iloc[1000:5000]也是——这些操作几乎不增加内存 - 但
df[df.col > 0]布尔索引后，若结果行不连续，Pandas可能退化为副本；此时可加.copy(deep=False)强制尝试浅拷贝，或改用df.query('col > 0')（内部优化更激进） - 列式存储引擎（如Arrow-backed DataFrame）中，单列视图开销趋近于零，适合按需提取字段做轻量清洗
就地修改（inplace）：直接覆写原内存块
设置 inplace=True 可绕过返回新对象的步骤，直接修改原DataFrame底层数组。这不是“省一步赋值”，而是彻底避免副本分配。
-
df.drop(columns=['tmp_col'], inplace=True)比df = df.drop(columns=['tmp_col'])内存峰值低30%~90%，尤其在多列批量删除时效果显著 - 注意限制：
inplace=True对sort_values、reset_index等涉及重排的操作仍可能触发内部副本；此时应优先用df.sort_values(..., kind='mergesort')（稳定排序，更易复用内存） - 高危操作如
df.loc[condition, 'col'] = value默认就地，但若condition导致隐式升维（如混合索引），可能意外创建副本——建议配合df._mgr.blocks观察内存块变化
实际清洗流水线中，三者应分层使用：用视图快速定位脏数据范围，用就地修改执行高频操作（去重、填充、类型转换），仅在跨阶段聚合或输出终版时才显式构造最小化新对象。内存不是被“释放”掉的，而是从一开始就没让它被分配出来。
