pd.NA与np.nan混合运算时行为不一致：算术运算均传播缺失，但比较运算中pd.NA==pd.NA返回pd.NA（未知），np.nan==np.nan返回False；混合列比较结果为pd.NA而非False。
pd.NA 与 np.nan 混合时，算术和比较运算会怎样？
混合使用 pd.NA 和 np.nan 会导致行为不一致甚至报错——这不是 bug，而是设计使然：pd.NA 是“三值逻辑”（True/False/Unknown）的缺失表示，而 np.nan 是 IEEE 浮点标准下的特殊值，仅在数值上下文中传播。两者在 pandas 3.0+ 中虽被“统一处理”，但底层语义仍不同。
-
pd.NA + 1→ 返回pd.NA（传播缺失） -
np.nan + 1→ 返回np.nan（符合 IEEE 规则） -
pd.NA == pd.NA→pd.NA（未知，不返回 True/False） -
np.nan == np.nan→False（IEEE 强制） - 若一列含
pd.NA、另一列含np.nan，做df['a'] == df['b']，结果中对应位置是pd.NA，不是False
为什么 df.replace(..., pd.NA) 后计算突然报错？
常见于升级 pandas 后用 pd.NA 替换字符串型缺失值，但未同步转换列类型。例如整数列原为 int64，pd.NA 无法存入，pandas 会静默转成 Int64（可空整数类型），但若后续代码仍按 int64 假设做 .astype(int) 或传给只接受原生 int 的库（如某些 C 扩展），就会抛 TypeError。
- 检查列类型：用
df.dtypes看是否已变成Int64、boolean、string等 nullable 类型 - 强制转换前先确认：比如
df['col'].astype('Int64')安全，但df['col'].astype(int)会失败 - 避免混用：不要在同一个 DataFrame 中让部分列用
pd.NA、部分列用np.nan；统一用df.convert_dtypes()自动转为 nullable 类型
如何安全地做混合缺失值的填充或聚合？
别手动判断 pd.NA 还是 np.nan——pandas 提供了统一接口。所有 isna()、fillna()、dropna() 都能同时识别 pd.NA、np.nan、None、NaT。但注意：默认 fillna(0) 对 pd.NA 有效，对 np.nan 也有效；而 fillna(pd.NA) 则可能触发类型转换（如把 float64 列转为 Float64）。
- 填充推荐写法：
df.fillna(0)或df.fillna({'col1': 0, 'col2': 'unknown'})，无需区分缺失类型 - 聚合时缺失值默认被跳过（如
sum()、mean()），但pd.NA在布尔列中参与all()/any()会返回pd.NA，而非False；需显式用skipna=False控制 - 避免用
df['x'] == np.nan或df['x'] is None判断缺失——一律用df['x'].isna()
实际项目中该选 pd.NA 还是 np.nan？
取决于你是否需要类型保真和语义清晰。如果数据含整数、布尔、字符串且允许缺失，pd.NA + nullable dtypes 是唯一能保持类型语义的方式；如果只是快速清洗、下游系统（如数据库 ORM、旧版 sklearn）只认 np.nan，那就坚持用 np.nan 并接受 float64 转换。
- 新项目建议起步就用
pd.NA，配合df.convert_dtypes()和pd.NA-aware 函数（如pd.array(..., dtype="string")） - 老项目迁移时，先跑
df.isna().sum()和df.applymap(type).nunique()查看缺失值混杂程度，再决定批量替换策略 - 关键提醒：
pd.NA仍是实验性标量（尽管 pandas 3.0 已广泛采用），其比较行为可能微调；生产环境若要求绝对稳定，可锁死 pandas 版本并禁用pd.NA，改用np.nan+ 显式类型注解
