用 loc 做条件筛选+赋值是唯一可靠且原地生效的方式；其他如 query 或链式索引无法更新原 DataFrame，易触发 SettingWithCopyWarning 或 copy-on-write 导致内存暴涨与性能下降。
用 loc 做条件筛选+赋值，别用 query 或链式索引
直接用 df.loc[condition, column] = value 是唯一可靠且原地生效的方式。很多人误以为 df.query(...).assign(...) 或 df[condition][col] = ... 能更新原 DataFrame，结果发现没生效——这是典型的 SettingWithCopyWarning 场景，背后是视图（view）和副本（copy）混淆。
-
df[condition][col] = ...一定不生效，Pandas 无法保证底层内存指向 -
df.query(...)总是返回新 DataFrame，后续赋值对原 df 零影响 -
loc显式声明“我要改这个位置”，Pandas 会尽力原地写入（除非触发 copy-on-write 机制） - 条件部分建议用布尔数组（
mask = df['x'] > 0），避免重复计算，尤其在多列更新时
大规模数据下，loc 更新慢？先检查是否触发了 copy-on-write
从 Pandas 2.0 开始默认启用 copy-on-write（CoW），看似安全，但会让原本原地更新的操作悄悄变成复制再改，内存翻倍、速度骤降。如果你发现 loc 更新变慢或内存暴涨，大概率是 CoW 在后台偷偷复制。
- 运行
pandas.options.mode.copy_on_write查看当前状态，True 表示开启 - 临时关闭：设
pandas.options.mode.copy_on_write = False（仅限可信脚本，非生产环境慎用） - 更稳妥做法：用
df._mgr._has_no_reference(...)检查列是否被引用；或用df.is_copy（已弃用但仍有提示作用） - 避免触发 CoW 的关键：不要从 df 切片出子集再改，比如
sub = df[df.x > 0]; sub.y = 1—— 这种写法必复制
更新多列时，loc 索引顺序影响性能
写成 df.loc[mask, ['a', 'b', 'c']] = [1, 2, 3] 比循环三次 df.loc[mask, 'a'] = 1 快得多，但要注意列顺序必须严格匹配赋值右侧的结构。
- 右侧若为 dict（
{'a': 1, 'b': 2}），Pandas 会按 dict 键顺序匹配列名，但不保证与loc中列列表顺序一致，容易错位 - 右侧若为 Series，index 必须与列名完全一致且顺序无关，但构造成本高，不推荐用于大批量
- 最稳写法：
df.loc[mask, cols] = np.array([[1,2,3]] * len(df[mask]))，但需确保 mask 非空，否则报 IndexError - 空 mask 时
df.loc[mask, cols]返回空 DataFrame，直接赋值会报错，务必提前判断if mask.any(): ...
替代方案：用 numpy.where 或 numexpr 加速布尔条件计算
当条件本身很复杂（比如嵌套逻辑、字符串 contains、多个列运算），loc 的布尔索引部分可能成为瓶颈。这时把条件计算从 Pandas 移到 NumPy 层，往往能提速 2–5 倍。
立即学习“Python免费学习笔记（深入）”；
- 简单条件如
df.x > 10 & df.y ，用 <code>np.where((df.x.values > 10) & (df.y.values 更快 - 含字符串操作（如
df.name.str.contains('abc')）极慢，换成numexpr.evaluate("df_name.str.contains('abc')")（需先import numexpr） - 注意：
numexpr不支持所有 Pandas 方法，只认基础数组操作，且要求变量提前传入命名空间 - 更新仍要用
loc，只是把左边的 mask 换成更快生成的布尔数组
实际场景中，真正卡住的往往不是“怎么写语法”，而是没意识到 CoW 的隐式复制，或在条件计算阶段就拖慢了整个流程。动手前先用 df.info(memory_usage='deep') 看内存占用，再用 %timeit 分段测 mask 生成和 loc 赋值耗时，比盲目调参数有用得多。
