Pandas链式索引（如dfcond=val）不可靠，因中间对象视图/副本不确定，赋值常静默失败；应统一用df.loc[cond, 'col'] = val确保可写性。
因为 Pandas 无法确定你操作的是原始 DataFrame 的视图（view）还是副本（copy），链式索引（如 df[condition]['col']）天然存在歧义，它不保证可写性——赋值可能静默失败，也可能偶尔生效，行为不可预测。
为什么 df[df['x'] > 0]['y'] = value 会触发警告
这不是误报，而是 Pandas 在明确提醒你：这行代码实际执行了两步——先用布尔索引生成一个中间对象（df[df['x'] > 0]），再对它的 'y' 列赋值。Pandas 不知道这个中间对象是原数据的视图（共享内存）还是独立副本（新开内存），所以不敢让赋值生效，只能发警告并大概率丢弃修改。
- 常见现象：
df[df['x'] > 0]['y'] = 999执行后，df里对应位置的值根本没变 - 更糟的情况：有时变、有时不变，取决于 DataFrame 构造方式、列类型（如
category）、是否刚经过merge或groupby等操作 - 根本原因：Pandas 的链式索引（chained indexing）不是原子操作，
.loc以外的任意两次[]或点号访问都属于链式
.loc 为什么能一招解决
.loc 是 Pandas 唯一被设计为“可写视图”的索引器，它把行筛选和列定位压缩进一次调用，绕过中间对象，直接告诉底层：“我要改原始 DataFrame 中这些标签位置上的值”。
- 正确写法：
df.loc[df['x'] > 0, 'y'] = 999—— 逗号不能省，否则会被当作纯行索引 - 多列赋值：
df.loc[df['x'] > 0, ['y', 'z']] = [999, 888]或广播标量：df.loc[df['x'] > 0, ['y', 'z']] = 0 - 注意索引对齐：
df.loc[condition, 'y']中的condition必须是与df同长度的布尔Series，别用df.query(...)的结果再套.loc，那又变链式了
什么时候才该用 .copy()
.copy() 不是用来“关掉警告”的，它是用来“明确隔离数据”的。如果你用了 .copy() 还想改原 df，逻辑上就矛盾了。
立即学习“Python免费学习笔记（深入）”；
- 合理场景：做探索性清洗，比如
df_test = df.copy(); df_test['new_col'] = df_test['a'] / df_test['b'] - 错误用法：
subset = df[df['x']==1].copy(); subset['y'] = 5→ 原df完全不受影响，但你以为改成功了 - 性能提示：
.copy(deep=False)不安全，仍可能共享底层数组；.copy(deep=True)内存开销大，仅在真需要深拷贝时用
真正容易被忽略的是：即使写了 .loc，如果原始 df 来自 read_csv 且某列为 category 类型，或条件结果为空（df['x']==999 全是 False），赋值也不会报错，但什么都不会发生——得自己检查布尔条件是否真有 True。
