Pandas数据清洗实战指南：从缺失值处理到异常值过滤

拿到一份数据，先别急着写代码。我见过太多人在数据清洗这个环节里，一上来就 dropna()、fillna(0)、astype(int) 一通操作，最后跑到建模阶段才发现数据分布已经面目全非，或者整整一列数据被默认参数悄悄吃掉了大半。Pandas 是数据清洗的绝对主力工具，但工具再怎么顺手，也顶不住清洗思路本身是乱的。

这篇文章我会完整走一遍我自己在项目里总结下来的 Pandas 清洗流程，不是把文档里的函数罗列一遍，而是讲清楚每一步为什么要这么做、容易在哪儿翻车、以及真实数据里最常见的那些恶心情况怎么处理。适合刚接触数据分析、准备用 Python 处理格式混乱数据的新手，也适合已经写了几个月脚本但总觉得哪里不对、清洗代码写得很啰嗦的同学。

1. 拿到数据先别动手：清洗前的体检比清洗本身更重要

很多教程上来就是 df.isnull().sum()，好像缺失值统计完就能开洗了。但我的习惯是，拿到任何一份数据，先花十分钟做"数据体检"，搞清楚三个底细：这份数据到底是什么、里面有哪些脏数据的形态、下游到底要拿这份数据怎么用。体检做明白了，清洗方案其实是顺水推舟的事。

1.1 用 info() 和 nunique() 快速给数据定性

先把 DataFrame 的结构摸清楚。df.info() 是我每次必看的第一眼，它把列名、非空数量、dtype 拉得明明白白：

python复制import pandas as pd

df = pd.read_csv("raw_data.csv")
print(df.info())

注意 Non-Null Count 这一列，它只告诉你每列非空的数量，但不会告诉你缺失值长什么样——这是后面要埋的坑，先记在心里。然后看每一列的去重数量，快速判断哪些字段是 ID、哪些是类别、哪些可能是生成了脏值：

python复制for col in df.columns:
    print(col, df[col].nunique())

如果一列是订单号，出现 10 万行但 nunique() 只有 2，不用多想，这列数据基本是废的。如果一列是年龄段，去重数应该是个位数到十几个，结果出现了上千个值，那里面大概率混入了下单时间、备注或者纯乱码，这种列直接拉出来看样本就行：

python复制df["年龄段"].value_counts().head(30)

这一步做下来，你会对数据整体状态有个直觉，接下来清洗的时候心里是有谱儿的。

1.2 清洗前必须想明白的三个问题

体检不仅是看代码输出，更重要是把下面三个问题过一遍：

1. 清洗的目标是什么？ 是给机器学习模型做输入？还是给业务方出统计报表？模型对缺失值和异常值极其敏感，但报表可能只需要把明显错误的数据去掉就行。目标不同，清洗的激进程度完全不同。

2. 哪些列是真正要用的？ 很多人喜欢把所有列都洗得漂漂亮亮，这是浪费时间的源头。先跟需求方确认下游模型只用到哪几个字段，无关字段一句"缺失率太高，移除"就可以带过，没必要花两小时在一个根本不会被读取的地址字段上。

3. 这一轮清洗必须保留多少数据？ 如果删掉 30% 的行会导致样本量不足，那缺失值填充策略就得保守；如果数据量大得用不完，那面对可疑记录大胆删除是可以接受的。

这三个问题想清楚再动手，你的清洗代码会简洁一半，因为你终于知道自己在干什么了。

2. 缺失值处理：先给缺失"分类判刑"，再谈删除还是填充

缺失值处理是数据清洗里最日常、也最容易被糊弄过去的一块。我见过太多人一遇到 NaN 就 fillna(0)，理由仅仅是"这样跑起来不报错"。但缺失值是有形态的，不同形态有不同的处理策略。

2.1 缺失不是只有一种形态：NaN、空字符串、占位符

先说一个新手最容易踩的雷：缺失值不一定以 NaN 的形式出现在 DataFrame 里。真实业务数据里，缺失值的常见形态还包括：

• 空字符串 ''，Excel 导出的文件大量这样；
• 占位符 "-"、"NULL"、"未知"，某些老系统的固定写法；
• 整列都是空格 " "，肉眼看不见，程序也判断不了；
• 数值类型的 0，它会被当作正常值，但在某些业务下它其实代表"无记录"。

所以 pd.isnull() 给出的结果永远是偏乐观的。我拿到外部数据，第一件事就是把所有 object 列替换成缺失值标准形态：

python复制def standardize_missing(df):
    # 常见占位符统一转为 NaN
    placeholder_values = ["", "-", "NULL", "null", "None", "N/A", "未知", " ", "\\N"]
    for col in df.columns:
        if df[col].dtype == "object":
            df[col] = df[col].str.strip().replace(placeholder_values, pd.NA)
    return df

这里有个关键细节，str.strip() 要在 replce 之前做，否则 " NULL " 这种带空格的值匹配不上。

2.2 按缺失比例决定删除还是填充

清洗策略不能一律化，我一般按缺失比例分成三档，参考下表处理：

但比例不是唯一依据。关键业务的字段哪怕缺失 10% 也要认真填充，而一个日志备注字段缺 80% 也不影响建模，直接删列就行。 不要机械套比例，结合下游用途来决定。

2.3 填充策略必须跟着数据分布走

填充值别一上来就填均值，均值是最懒也是风险最高的做法。连续型数据我习惯先看分布：如果数据基本服从正态分布，中位数和均值差异不大，可以考虑均值；如果数据偏态严重（比如收入、消费金额这类长尾分布），中位数远远好于均值，因为你用均值填充会把整体中心拉向那 5% 的高消费用户。

python复制# 看一下分布再决定
df["消费金额"].describe()
df["消费金额"].hist(bins=50)

如果是类别型字段，优先填众数。但再多想一步：众数只在大多数样本属于同一类别时才有意义。两个类别比例是 40% 和 35%，你填了 40% 那个，相当于给 35% 的用户强行换了标签。这类情况我一般会新增一个"未知"类别，把缺失单独做成一个分支。

时间序列数据又有不同玩法，前后填充 ffill() / bfill() 往往比全局均值合理得多——用户今天没出勤，昨天的数据比三个月的平均值更能说明问题。

提示：填充一定要留下审计痕迹。新建一列记录"该样本是否缺失过原值"，后续模型跑出奇怪结果时，你能快速判断是不是填充策略惹的祸。

3. 重复数据处理：去重之前，先确认业务上什么叫"重复"

df.drop_duplicates() 是用法最简单、后果最容易不可逆的函数之一。它默认基于所有列判断重复，这在很多真实场景下是个灾难级的默认行为。

3.1 subset 参数才决定了去重的业务语义

举个典型例子。一个订单明细表，每个用户可能分多次下单，每次买好几件商品。如果按所有列完全一致去重，那确实能去掉真正重复的录入记录；但如果用默认参数重跑一遍，同一用户同一天订了同样的商品，明明是不同的两个订单，却被当作重复删掉了。

正确做法是先用业务口径界定哪些列应该唯一。比如"一条用户每日浏览记录"，那去重应该按 用户ID + 日期 来看：

python复制df = df.drop_duplicates(subset=["user_id", "biz_date"], keep="first")

keep 参数同样值得细抠。keep="first" 保留重复组的第一条，keep="last" 保留最后一条，如果你的数据每次都追加前一天的全量快照，那“最后一条”很可能才是最新状态，keep="first" 会把你留下的是旧版本，这种坑我在某次做会员画像任务的时候踩得很彻底。

3.2 重复率检查：清洗前先把"家底"摸清楚

我建议在执行 drop_duplicates 前，先输出一遍重复情况：

python复制duplicated_rows = df.duplicated(subset=["user_id", "biz_date"])
print(f"重复行数: {duplicated_rows.sum()}, 占比: {duplicated_rows.mean():.2%}")

比例很低（比如千分之一），可以直接删；比例高到 5% 以上，就要怀疑不仅是重复，而是口径有问题了——可能是同一个用户被拆成了多个 ID，或者是同一条记录被多次写入。这时候先暂停去重，去查上游数仓的逻辑，清洗脚本写得再好也救不了源头故障。

3.3 去重后的索引重置，一个小动作省掉一堆麻烦

drop_duplicates 之后 DataFrame 的行号是有洞的，此时如果直接 reset_index() 还好，就怕你忘了做，后面 loc 定位或者合并的时候老出怪问题：

python复制df = df.drop_duplicates(subset=["user_id", "biz_date"]).reset_index(drop=True)

drop=True 的意思是丢掉原索引列，否则它会变成一个新列 index，白白增加一列。

4. 异常值的判断：不能只靠眼睛"看着不对"

异常值清洗是标准流程里最需要"讲道理"的环节。describe() 只能告诉你描述性统计量，真实世界的数据里，异常值往往不是因为数据采集错了，而是业务里"合理存在"的现象。直接删异常值之前，得先分清楚它是离群点、真错误、还是业务上的稀有但有效数据。

4.1 先看 describe() 的最大值和最小值，再往下挖

python复制df["订单金额"].describe()

最大值和 min 是最容易暴露问题的两项。订单金额最大值是 9,999,999，而次大值只有 20,000，不用统计分布，你就能猜到这是某次测试单或者录入错误；最小值如果是负数，那要看业务允不允许退款单混进来，不允许的话直接过滤掉即可。

但真实情况往往在"中间地带"更加暧昧。一个订单金额字段，正常的范围是 10 到 1000，但出现了 3500 的订单，这是异常还是正常大客户采购？仅凭统计你无法回答，必须去问业务方。这也是为什么我一直建议：异常值清洗永远要留一版原始数据，不要覆盖原文件。

4.2 用 IQR 和 Z-score 把"离群"量化

最常用的两个方法是 IQR（四分位距）法和 Z-score 法。

IQR 的处理思路是把超出 Q3 + 1.5 * IQR 或低于 Q1 - 1.5 * IQR 的点标记出来：

python复制Q1 = df["订单金额"].quantile(0.25)
Q3 = df["订单金额"].quantile(0.75)
IQR = Q3 - Q1

lower_bound = Q1 - 1.5 * IQR
upper_bound = Q3 + 1.5 * IQR
outliers_iqr = df[(df["订单金额"] < lower_bound) | (df["订单金额"] > upper_bound)]

Z-score 则是看数据偏离均值多少个标准差，一般超过 3 个标准差视为离群：

python复制from scipy import stats

z_scores = stats.zscore(df["订单金额"])
outliers_zscore = df[abs(z_scores) > 3]

两种方法的结果是可以互相印证的，如果某个点同时被两种方法标记为离群，那它是真离群点的概率非常大。但注意，IQR 和 Z-score 都假设数据本身近似正态或至少对称，长尾分布下这两个方法会误杀许多真实的高值用户。保险做法是：清洗前先用 hist() 和 boxplot 看一眼形态，确认了分布再决定用哪个阀值。

4.3 异常值不一定非要删：标记出来也是一种清洗

很多场景下，异常值不应该被直接扔进垃圾桶，而应该在清洗完的 DataFrame 里加一个 is_outlier 布尔列。模型训练时有理由把异常样本剔除，但在业务看板、风控分析里，这类"异常"本身就是业务人员要研究的对象。举例来说，某零售数据里有一批金额高得离谱的批发单，删除之后销售额反而失真了，保留并标记反而能让下游分析更立体。

5. 数据类型统一：最琐碎、最烦人、最容易爆炸的一步

数据清洗里我花时间最多的地方，不是缺失值也不是异常值，而是看起来毫无技术含量的"类型转换"。原因就一个：真实数据源的类型从来不会按照你希望的样子出现。

5.1 astype() 不是万能药：object 列里的数字和单位混写

astype(int) 在遇到 "1,200"、"1200元"、"1.2k" 这类花式写法时，会直接抛错或者输出让人困惑的结果。清洗的节奏必须是：先规整字符串，再转类型。

比如金额字段经常带"元"、"万"后缀，或者千分位逗号。我一般会写一个函数把这类字符串清洗成可用的数值列：

python复制def clean_amount(series):
    return (
        series.astype(str)
        .str.replace(",", "", regex=False)
        .str.replace("元", "", regex=False)
        .str.replace(" ", "", regex=False)
        .str.replace("万", "0000", regex=False)
        .astype(float)
    )

这里有个细节：把"万"替换成"0000"要当心，如果数据里同时出现了"1.2万"和"8000"，直接替换会变成 1.20000，数值一下膨胀十倍。更稳妥的做法是写一个逐行解析函数，检测 "万" 就把前面部分乘以 10000。

python复制def convert_wan_to_number(text):
    text = str(text).replace(" ", "").replace("元", "")
    if "万" in text:
        base, _ = text.split("万")
        return float(base) * 10000
    try:
        return float(text)
    except ValueError:
        return None

df["金额"] = df["金额"].apply(convert_wan_to_number)

这样的逐行解析比无脑 replace 要安全得多。把单位统一逻辑想清楚，一段函数能一次性处理掉全列的脏数据。

5.2 日期格式的"潘多拉魔盒"：time 解析必须给格式兜底

日期列是另一个重灾区。2024/1/5、2024-01-05、20240105、03/05/2024（到底是 3 月 5 号还是 5 月 3 号？），几种格式混在一个 CSV 里，你就知道 pd.to_datetime 为什么总在报错。

我的经验是用 format 参数显式声明，而不是让 Pandas 自动猜：

python复制df["下单日期"] = pd.to_datetime(df["下单日期"], format="%Y-%m-%d", errors="coerce")

errors="coerce" 的作用是，解析不了的统一变成 NaT。解析完之后再回来看看 isna() 的比例，如果异常比例过高，多半不是格式问题，而是混入了中文日期或纯数字日期，这时候再根据实际情况补一段预处理。

5.3 把边界测量值转成 category，是清洗的收尾动作

有些列的类型转换不是为了计算，而是为了让存储和分析更高效。比如性别只有"男/女"两个取值，城市名也就几百个取值，这些列从 object 转为 category，运行内存会显著下降，groupby 性能也会更好：

python复制df["性别"] = df["性别"].astype("category")
df["所属城市"] = df["所属城市"].astype("category")

注意，category 类型在后续 fillna 或 replace 时要先把类型转回 object 再操作，否则个别版本的 Pandas 会出现异常行为。这种"莫名 bug"查起来极费时间，提前了解能省很多事。

6. 清洗中的几个"闷棍"：索引混乱、链式赋值和性能陷阱

到这里，清洗的主流程已经走完一大半，剩下的是那些你在教程里看不到、但实操中必然撞上的怪问题。这一节我挑三个最经典的"闷棍"来讲，每一个都曾经让我在深夜抓掉过头发。

6.1 SettingWithCopyWarning 的根本原因，不是你的"赋值"有问题

这个警告很多新手遇到就直接忽略，但老手看到它就知道代码里有隐患。它本质上是在提醒你：你可能在修改一个临时副本，而不是原 DataFrame。

典型场景：

python复制sub_df = df[df["金额"] > 100]
sub_df["flag"] = 1  # 这里可能触发 SettingWithCopyWarning

df[df["金额"] > 100] 返回的可能是一个视图（View），也可能是一个副本（Copy），取决于 Pandas 的内部实现。你在视图上做了修改，Pandas 不确定这次修改会不会同步回原 DataFrame，干脆警告你一句。

干净的做法是：如果想要一个独立子集并修改它，使用 .copy()：

python复制sub_df = df[df["金额"] > 100].copy()
sub_df["flag"] = 1

如果是想改原来的 DataFrame，就直接用布尔索引在原对象上操作：

python复制df.loc[df["金额"] > 100, "flag"] = 1

6.2 循环遍历行去清洗？能不用就别用

我见过有人处理数据清洗时写 for index, row in df.iterrows()，几千行数据慢得不行，还会遇到"行里明明是数字，取出来却变成了字符串"之类的诡异类型变化。Pandas 的设计哲学就是尽可能地用向量化操作代替循环——apply 或 map 已经能覆盖绝大部分逐行处理的场景。

拿"根据身份证判断性别"这种清洗需求举例。正确的做法是先定义好函数，然后整个列一起 apply：

python复制def judge_gender_from_idcard(id_card):
    try:
        return "女" if int(id_card[-2]) % 2 == 0 else "男"
    except (ValueError, TypeError):
        return None

df["推断性别"] = df["身份证号"].apply(judge_gender_from_idcard)

很多清洗过程还适合用 np.where 或者布尔掩码批量赋值，比如"金额为空但订单状态为已支付"的样本，完全可以用两行布尔逻辑直接标记出来，用不上循环。

6.3 清洗规则有没有必要打包成函数

这是一个一直在争论的问题。我的建议是：如果这份数据清洗只是一次性的临时任务，直接写逐步的脚本没问题；但如果公司每个月都要从同样的数据源清洗数据、跑同样的流程，那就必须把清洗过程封装成可复用的函数，形成标准清洗流水线。

我日常偏向这样组织：

python复制def load_raw_data(path):
    df = pd.read_csv(path)
    return df

def clean_missing_values(df):
    # 缺失值规整与填充
    return df

def clean_deduplicate(df):
    # 按业务口径去重
    return df

def clean_types(df):
    # 类型统一与格式规整
    return df

def main():
    df = load_raw_data("raw_data.csv")
    df = clean_missing_values(df)
    df = clean_deduplicate(df)
    df = clean_types(df)
    df.to_csv("cleaned_data.csv", index=False)

if __name__ == "__main__":
    main()

这套结构的好处有三个：每个环节可以单测、出问题时可以单独跑某一个函数、换一份新数据时可以直接复用。把每个清洗动作限定在一个函数里，也强迫自己把"为什么这么洗"的逻辑用函数名和注释记录下来——这份记录比代码本身值钱得多。

7. 收尾的最后一个检查：清洗完的数据真的"干净"了吗

做完一整套清洗，不急着交付，我习惯再跑一遍"清洁度检查"，用代码确认清洗效果，也算是给这一轮工作一个交代。步骤很简单：看 info() 确认各列非空数量基本合理、看 describe() 比较清洗前后的极值和分位数、抽样打印几行肉眼过一遍、最后用 assert 做硬性校验：

python复制assert df["订单金额"].isna().sum() == 0, "金额列仍有缺失"
assert df["下单日期"].min() >= pd.Timestamp("2020-01-01"), "日期范围异常"
assert df["订单号"].is_unique, "订单号存在重复"

这四条 assert 跑通了，基本可以放心把数据交给下游。我在实际项目中，通常还会顺手保留一份清洗前的原始备份文件和一个清洗规则说明 Markdown，写清楚每一列发生了什么变化、删了多少行、填了什么值。等某个深夜下游模型效果异常、别人来问你"你这数据到底洗了什么"的时候，这份记录就是你的护身符。

我个人的经验是，Pandas 数据清洗的核心从来不是代码写得多么花哨，而是"每一步改动都知道为什么、改完之后知道改了什么"。坚持这个习惯，数据质量会稳定得多，你在项目里的时间也能从无穷无尽的补数据中解放出来一些。