用replace()批量替换伪空值为np.nan需用字典映射全表替换，避免仅传标量导致漏改；注意object列中np.nan可能不被isna()识别，应优先在read_csv时用na_values预设空值。
用 replace() 批量替换为 np.nan 最直接
想把 DataFrame 里所有 -999、999、"N/A" 这类“伪空值”统一转成标准的 np.nan，replace() 是首选。它支持字典映射、列表匹配和正则，且默认就原地生效（inplace=False，所以要显式赋值或加 inplace=True）。
常见错误是只传一个标量（如 df.replace(-999, np.nan)），结果只改第一列或报错——因为 Pandas 默认只作用于数值列，遇到字符串列会跳过或抛 TypeError。正确做法是明确指定作用范围：
- 全表替换（推荐）：
df = df.replace({-999: np.nan, 999: np.nan, "N/A": np.nan}) - 仅某几列：
df[["age", "score"]] = df[["age", "score"]].replace([-999, 999], np.nan) - 字符串列专用（避免数字列误伤）：
df["status"] = df["status"].replace(r"^\s*$|N/A|NULL", np.nan, regex=True)
replace() 和 where() 的适用边界在哪
replace() 是“找值替换”，适合已知具体标记值；where() 是“按条件留值”，适合动态逻辑（比如“所有大于100的值设为空”）。两者性能接近，但语义不同，混用容易出错。
典型误用：df.where(df != -999, np.nan) 看似等价，实则会把原本就是 np.nan 的位置也参与比较，触发 nan != nan → True，导致原 np.nan 被意外覆盖。正确写法是先用 mask() 或组合 isna()：
立即学习“Python免费学习笔记（深入）”；
- 安全的条件置空：
df = df.mask(df.isin([-999, 999])) - 带类型保护（防止字符串列报错）：
df = df.apply(lambda s: s.replace([-999, 999], np.nan) if s.dtype in ["int64", "float64"] else s)
替换后 isna() 不生效？检查数据类型是否被隐式转成 object
如果替换完发现 df.isna().sum() 没有增加，大概率是某些列被 Pandas 自动转成了 object 类型（尤其是混合了数字和字符串的列），而 np.nan 在 object 列中虽可存在，但部分操作（如 dropna()）可能不识别。
验证方式：df.dtypes 查看各列类型；修复方法：
- 强制转数值并置空：
df["col"] = pd.to_numeric(df["col"], errors="coerce")（会自动把非数字转np.nan） - 替换后再统一转类型：
df = df.astype({"age": "Int64", "score": "float64"})（注意"Int64"是 Pandas 可空整型） - 避免 object 列污染：替换前先分离处理，别让
replace()跨类型列批量跑
大文件下替换慢？优先用 pd.read_csv(..., na_values=[...])
如果原始数据来自 CSV，最省事的方式不是读进来再替换，而是在读取阶段就声明哪些值算空值。这样既快又干净，还能避免后续类型推断错误。
na_values 支持列表、字典（列名→值列表）、甚至字符串（如 "NULL"），但要注意：
- 默认已包含
["", "#N/A", "#N/A N/A", ...]，重复定义不会冲突 - 若文件含引号包裹的
"-999"，需确保keep_default_na=True（默认开启） - 对整数列，
na_values设定后仍可能因缺失值存在而转为float64；如需保持整型，后续加astype("Int64")
真正麻烦的是嵌套在 JSON 或数据库导出里的自定义标记——那种就得老实用 replace()，而且得提前确认标记是否带空格、大小写、不可见字符。
