Pandas中inplace=True基本不生效，多数方法如dropna()、fillna()等已忽略该参数并返回新对象；真正原地修改仅限列赋值、iloc小范围赋值等少数场景，需用id()验证底层数组是否变化。
inplace=True 在 Pandas 里基本不生效，别信文档旧说法
从 Pandas 1.5 开始，inplace=True 已被大量废弃或降级为“仅作兼容保留”，实际调用时多数方法（如 dropna()、fillna()、sort_values()）会直接忽略该参数，仍返回新对象——但不报错，也不警告。你看到 DataFrame 像被改了，大概率是误以为视图操作=原地修改，或是恰好触发了底层内存共享（比如切片未拷贝）。真实场景中依赖 inplace=True 实现“节省内存”或“避免赋值”，几乎必然失败。
哪些操作真能原地改，哪些只是假象？
真正支持底层内存复用的只有极少数操作，且依赖具体数据结构和 dtype：
-
df.loc[:, 'col'] = new_values：对已有列赋值，只要new_values类型兼容且未触发块拆分（block manager 重组），就是原地；但若列是 object 类型，赋入 list 或 None，可能悄悄转成 object block 并复制 -
df.iloc[rows, cols] = ...：同理，小范围索引赋值较安全；整列替换建议用df['col'].values[:] = ... -
df._mgr.blocks[0].values[:] = ...：绕过 API 直接改底层数组——有效但极度危险，Pandas 内部结构随时可能变，不推荐 -
df.drop(columns=['a'], inplace=True)：看似 in-place，实则内部仍新建 BlockManager，旧数据未释放，GC 前内存不降
大表处理时更可靠的“伪原地”策略
与其赌 inplace=True，不如主动控制副本时机和粒度：
- 用
del df['unused_col']+gc.collect()显式删列并促回收，比drop(..., inplace=True)更可控 - 对超大数值列做计算，优先用
df['col'].values获取 NumPy 数组，就地运算（如arr *= 2），再写回：df['col'].values[:] = arr - 读取 CSV 时加
usecols和dtype精确约束字段类型，避免后续因类型推断被迫复制整块内存 - 链式操作必须打断：不要
df.dropna().fillna(0).sort_values(...)，而要分步 +del中间变量，尤其在循环中
如何验证某次操作是否真的没复制？
最简单方式是比对底层数组 ID：
立即学习“Python免费学习笔记（深入）”；
original_id = id(df['col'].values) df['col'] = df['col'] * 2 # 或其他操作 new_id = id(df['col'].values) print(original_id == new_id) # True 才算真原地
注意：这个判断只对数值列可靠；category/string 类型涉及编码表，.values 可能返回 view 或 copy，需结合 df['col'].array 或 _mgr 检查。另外，即使 ID 不变，若操作触发了 __setitem__ 的 block consolidation（比如混入 NaN 后 dtype 升级），后续操作仍可能突然复制。
真正的大表安全修改，核心不是找“哪个函数带 inplace”，而是理解 Pandas 的 block manager 行为、主动管理引用、并在关键节点用 id() 或 sys.getsizeof() 验证内存变化。靠参数开关，迟早踩坑。
