Pandas筛选与过滤全解析：布尔索引、loc/iloc与query

1. 为什么"筛选"是Pandas里最不该被低估的一步

1.1 从一次逐行判断的返工说起

前阵子帮一位做运营分析的同行看代码，他想从一张几万行的订单表里挑出"区域A且金额大于100且状态为已支付"的记录，写出来的东西是这样的：先iterrows()遍历，再用 if 判断，符合条件的 append 到一个空列表里，最后pd.DataFrame(list)。跑是能跑，但耗时接近两分钟，而且新表丢了原始索引和数据类型，后续按日期排序时 created 列变成了 object，sort_values的结果全乱。

这段代码的问题不在逻辑，而在于他没有把Pandas的数据筛选和过滤当成一种"向量化的表达"来理解。Pandas里绝大多数筛选，本质都是"生成一个布尔序列，然后拿它去挑行"，一次运算作用于整列，而不是一行一行地问"你符合条件吗"。这篇是Pandas专栏第九章的第一部分，我想把筛选和过滤这一块彻底讲透——从最底层的布尔索引，到 loc/iloc 的分工，再到 query、isin、between、字符串匹配，最后落在那些让人排查半天的坑上。适合刚学会read_csv和groupby、但一到复杂条件就写成循环的读者，也适合已经能写但不确定"为什么这么写"的读者。

1.2 筛选在分析链路里的真实位置

很多人把筛选当成"取数据"的辅助动作，实际它出现的位置远比想象中密集。拿到一张表，第一件事往往是看子集：某个时间段的、某个区域的、某个状态的；做特征工程前要先剔除异常值；做分组聚合前要先排除无效记录；做可视化前要圈定范围。也就是说，筛选质量直接决定了后面所有环节的输入质量。

我把日常遇到的筛选需求粗略归成四类：单列条件（金额大于多少、状态等于什么）、多列组合条件（且、或、非的嵌套）、集合与区间命中（在某个列表里、落在某个范围内）、文本与缺失值匹配（包含某关键词、字段为空）。这四类覆盖了九成以上的实际场景，而它们最终都会被翻译成同一种东西——布尔掩码（boolean mask）。理解这一点，后面所有写法就都能串起来了。

提示：判断自己是否真的理解了筛选，有个很简单的标准——能不能在不查文档的情况下说清楚df[df.a > 1]里那一层中括号到底在做什么。说不清的话，第 2 节值得慢慢看。

2. 布尔索引：所有花式筛选最终都落回这里

2.1 一次比较背后发生了什么

先构造一份贯穿全文的示例数据，虚构的订单信息，字段尽量贴近真实业务：

import pandas as pd import numpy as np df = pd.DataFrame({ "order_id": [1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008], "region": ["区域A", "区域B", "区域A", "区域C", "区域B", "区域A", "区域C", "区域B"], "amount": [120.5, 88.0, 300.0, 45.9, 210.0, 99.9, 520.0, np.nan], "status": ["paid", "paid", "refund", "paid", "paid", "unpaid", "paid", "paid"], "channel": ["线上", "线下", "线上", "线上", "线下", "线上", "线下", "线上"], "created": pd.to_datetime([ "2024-01-01", "2024-01-03", "2024-01-05", "2024-01-08", "2024-01-12", "2024-01-15", "2024-01-20", "2024-01-25" ]) })

写df["amount"] > 100这一句的时候，实际发生的是：df["amount"]取出一个 Series（长度 8），> 100触发 Series 的逐元素比较，得到一个长度同样为 8、dtype 为 bool 的 Series，索引与原来完全一致。df[...]收到这个布尔 Series 后，按位置把 True 对应的整行挑出来，索引原样保留。

mask = df["amount"] > 100 print(mask) # 0 True # 1 False # 2 True # 3 False # 4 True # 5 False # 6 True # 7 False result = df[mask]

这里有个容易被忽略的细节：结果的行索引是[0, 2, 4, 6]，不是重新编号的[0, 1, 2, 3]。这不是 bug，是Pandas刻意保留的"原始身份"。保留索引的好处是后续可以用.loc精确回指原表，坏处是导出、拼接、按位置取值时容易错位。什么时候该重置，第 7 节会细讲。

2.2&|~和andornot的区别

这是新手翻车率最高的一个点。Python 的and/or/not是短路求值的逻辑运算符，它们要拿到一个明确的真假值才能决定要不要继续算右边。而 Series 的真假是"一堆 True 和一堆 False"，没法压成一个值，于是会直接抛ValueError: The truth value of a Series is ambiguous。

正确的写法是对应位运算符：

&、|、~在Pandas和 NumPy 里被重载成了逐元素运算，这是它们和 Python 内置关键字本质不同的地方。记忆方式很简单：对象是标量就用 and/or/not，对象是序列就用 &/|/~。

2.3 括号与优先级：最容易翻车的一行

位运算符的优先级高于比较运算符，这个说法听起来抽象，看下面这行就明白了：

# 想表达：区域A 且 金额 > 100 bad = df["region"] == "区域A" & df["amount"] > 100 # 报错或结果错误

&会先和"区域A"结合，而字符串和浮点数之间做位运算直接报TypeError。即使不报错（比如两边都是整数），语义也完全跑偏。正确写法必须给每个条件单独加括号：

good = (df["region"] == "区域A") & (df["amount"] > 100) print(df[good])

我在团队里推过一条硬规矩：只要一行里出现两个及以上条件，每个条件无条件加括号，哪怕逻辑上不需要。原因很现实——代码审查时没人愿意去查运算符优先级表，加了括号的代码一眼就能看出条件边界，后续加第三个条件也不会出错。

顺带说下"非"的写法。想排除某个区域，可以写~（df["region"] == "区域A")，也可以写df["region"] != "区域A"。前者在组合条件里更灵活，比如"非（区域A且已支付）"只能用~(cond1 & cond2)表达；后者可读性更好。我的习惯是单一条件取反用!=，复合条件取反用~()。

2.4 索引对齐带来的意外结果

布尔索引对索引对齐是敏感的。如果拿到的掩码不是来自同一张表，而是外部传进来的、或者已经被过滤过的 Series，Pandas会按索引名对齐，对不上的位置补 NaN，然后报错：

other_mask = pd.Series([True, True], index=[0, 1]) df[other_mask] # ValueError: Cannot mask with non-boolean array containing NA / NaN values

这种报错信息很误导人，它说"包含 NaN"，但你明明传的是纯布尔。真实原因是df的索引是 0~7，而other_mask只有 0 和 1，其余位置对齐后成了 NaN。解决办法是传数组而不是 Series：df[other_mask.to_numpy()]，或者other_mask.reindex(df.index, fill_value=False)。

同样的问题也会出现在两个 Series 做&运算时。如果两张表的索引顺序不同，s1 & s2会按索引标签对齐而不是按位置，结果可能和你预期完全不同。我遇到过最隐蔽的一次是：两张表都是按时间排序的，但一张的索引是从 0 开始，另一张做过一次筛选后索引是[3, 7, 12, ...]，两者一&，结果大半个表是 False。排查了半小时才发现根因。

提示：任何来自"另一张表"或"上一次筛选结果"的 Series，在做逻辑运算或作为掩码之前，先print(mask.index[:5])看一眼索引长什么样，能省掉大量时间。

3. loc 与 iloc：行列同时定位时怎么选

3.1 两者的边界在哪里

loc和iloc的区别不在于"一个按标签一个按位置"这么简单，真正的区别在于它们对索引的解释方式，而这个差异会直接影响切片行为和赋值行为。

• loc的所有维度都按索引标签解释，包括切片的两端。
• iloc的所有维度都按整数位置解释，语义上等价于列表下标。

判断标准其实就一条：你脑子里的那个数字，是"第几行"还是"索引名叫什么"。如果df的索引就是默认的 0~n-1，两者看起来结果一样，但一旦做过筛选、排序或者set_index，差别立刻显现。

sub = df[df["status"] == "paid"] # 索引变成 [0, 1, 3, 4, 6, 7] sub.loc[3] # 取索引标签为 3 的行 -> order_id 1004 sub.iloc[3] # 取第 4 行 -> order_id 1005

同一句3，结果差了整整一行。这就是为什么我强烈建议：只要数据经历过一次筛选，就不要再用iloc做业务取值，除非你确实只关心物理位置。

3.2 切片右端点是否包含，这是个大坑

loc的切片是闭区间，iloc的切片是左闭右开，这个差异和列表、range的习惯正好对不上，是另一个高频翻车点：

s = df.set_index("order_id") s.loc[1001:1003] # 包含 1001、1002、1003 三行 s.iloc[0:3] # 包含位置 0、1、2 三行 s.iloc[0:2] # 只有两行

看上去loc[1001:1003]和iloc[0:3]结果数量一样，那是因为 1003 恰好是第三个。换个范围就露馅了。我自己的规避方式是：loc用标签时明确写出两端，iloc只在大批量按块取样时用，并且在旁边写注释说明是左闭右开。

还有一个细节：loc的切片如果端点不存在，不会报错，而是按排序关系取范围内的行；iloc的越界切片会抛IndexError。这个行为差异有时能救命——比如按日期区间取数，loc["2024-01-01":"2024-01-10"]，即使当天没有数据也能正常返回空或部分数据，而不用先判断存在性。

3.3 布尔加列选择的写法

loc最实用的场景是"行条件 + 列选择"一步到位：

df.loc[df["amount"] > 100, ["order_id", "region", "amount"]]

这里第一个参数是布尔掩码，第二个参数是列名列表，返回的是一个新的 DataFrame，索引保留。等价的两步写法是df[df["amount"] > 100][["order_id", "region", "amount"]]，但两种写法在赋值时行为完全不同，这点在第 7 节会展开。

还有一个很顺手的小技巧：列条件也可以用切片，df.loc[mask, "amount":"created"]能按列顺序取一段连续的列，适合字段很多、顺序又固定的宽表。不过要注意loc的列切片同样包含右端点，且按的是原始列顺序而不是你想象的顺序。

3.4at/iat与高频取值

如果只是取单个值，at和iat比loc/iloc快，因为它们跳过了对齐和类型检查的部分开销：

df.at[0, "amount"] # 按标签 df.iat[0, 2] # 按位置

实测在十万行量级上，单次取值能快出三四倍。但注意at只能取标量，不能取切片；而且如果键不存在，直接报KeyError，不像loc那样在某些情况下返回空 Series。我的用法是：循环里高频取单元格用at/iat，其余一律loc。

4. query：把筛选条件写成一眼能读懂的句子

4.1 query 到底做了什么

条件一多，括号嵌套起来就变成这样：

df[(df["region"] == "区域A") & (df["amount"] > 100) & (df["status"] == "paid")]

说实话，写的时候没错，读的时候要数括号。query把这层结构拍平成一个字符串表达式，Pandas内部解析后再翻译成布尔运算：

df.query("region == '区域A' and amount > 100 and status == 'paid'")

注意query里可以用and/or/not，因为它是把字符串当表达式解析的，不经过 Python 的短路求值，避开了第 2.2 节那个问题。这是个很实用的区别——同一套条件在query里写起来更像 SQL，可读性明显更好。

query的实现走的是numexpr（如果装了）或 Python 的eval，表达式里的列名会被替换成对应的 Series 或底层数组。所以它支持算术、比较、逻辑、成员运算（in、not in），也支持变量引用。

4.2 外部变量、列名带空格与反引号

query里引用 Python 变量要在前面加@：

threshold = 100 region_list = ["区域A", "区域B"] df.query("amount > @threshold and region in @region_list")

这个@语法是query特有的，很多人第一次见会愣一下。它解决的是"表达式字符串和 Python 命名空间隔离"的问题——不加@，query会把threshold当成列名去找，找不到就抛UndefinedVariableError。

列名带空格、中文标点或者和 Python 关键字冲突时，要用反引号包起来：

df.rename(columns={"amount": "订单金额"}) \ .query("`订单金额` > 100")

反引号这个写法在query文档里藏得比较深，我第一次遇到时试了中括号、单引号、双引号全都不行，最后查源码才看到。

还有一个坑：字符串字面量要用引号包住，而外层你通常用的是双引号，所以内层只能用单引号，或者反过来。嵌套三层引号时建议直接抽成变量用@传进去，别硬写。

4.3 query 与布尔索引的取舍

两种写法不是替代关系，各自有明确的适用面：

性能上的差异在中等数据量（几万到几十万行）不明显，上到百万行、条件又多时，query配合numexpr的多线程计算会有优势。但我不建议为了性能提前切到query——先保证可读，测出来是瓶颈再换。

query真正的短板在调试。条件写错了，报错信息往往只说"某某未定义"或者"无法解析"，不像布尔索引那样能逐个 mask 打印出来看。我的做法是：复杂条件先拆成几个独立的布尔 Series 逐个验证，确认无误后再合并成一句query，两者不冲突，是"先验证后优化"的关系。

5. isin、between 和字符串匹配：三类高频场景的细节

5.1isin处理"多值命中"

要挑出某个字段属于一组值里的记录，用|串联等于号是最直接的想法：

df[(df["region"] == "区域A") | (df["region"] == "区域B")]

值一多就崩了。isin接收一个列表、集合或 Series，一次判断完：

df[df["region"].isin(["区域A", "区域B"])]

几个需要注意的点。第一，isin对NaN的处理是：只有当列表里显式包含np.nan时才匹配，否则NaN一律返回 False。这和第 6 节讲的"NaN 比较永远为 False"是一致的。第二，isin对值的类型敏感，1和"1"不相等，如果列里混了字符串和数字，命中结果会少一半。第三，传入集合（set）在大列表时比传列表快，因为查找是哈希。

反向操作用~：

df[~df["region"].isin(["区域C"])]

排除法在清洗数据时用得极多，比如排除测试账号、排除内部单、排除异常渠道。这里提醒一句：~df["col"].isin([...])会把该列的NaN也一并保留（因为isin返回 False，取反成 True）。如果你本意是"排除这些值，同时也要排除空值"，得写成df["col"].notna() & ~df["col"].isin([...])。

5.2between的开闭区间与日期

数值和日期的区间筛选，between(left, right)默认是双闭区间，等价于(x >= left) & (x <= right)：

df[df["amount"].between(100, 300)] df[df["created"].between("2024-01-05", "2024-01-20")]

inclusive参数控制端点："both"（默认）、"neither"、"left"、"right"。做分段统计时这个参数很关键——如果相邻两个区间都用闭区间，边界值会被算两次；都用开区间，边界值就漏了。我的习惯是分段统计统一用左闭右开：between(a, b, inclusive="left")，这样各段首尾相接、不重不漏。

日期区间有个隐藏要求：列的 dtype 必须是 datetime。如果是字符串，between("2024-01-05", "2024-01-20")走的是字符串字典序比较，对"2024-01-05"这种标准格式恰好能得到正确结果，但一旦格式不统一（比如混了"2024/1/5"），结果就彻底错了。所以筛选日期前先pd.to_datetime一遍，别赌格式。

5.3str.contains的na与正则问题

文本包含匹配是最容易出细节问题的一类：

df[df["status"].str.contains("pa")]

默认情况下contains的第一个参数是正则表达式而不是普通字符串。这意味着里面出现.、*、+、(、[这些字符时，会按正则语义解释。比如想找包含 "1.5" 的记录，contains("1.5")里的.会匹配任意字符，把 "1x5" 也捞进来。正确做法是contains("1\\.5")，或者干脆关掉正则：

df[df["status"].str.contains("1.5", regex=False)]

第二个问题更隐蔽：列里只要有NaN，contains就会返回NaN而不是 False，接着拿这个结果去索引就会报Cannot mask with non-boolean array containing NA / NaN values。解法是加na=False：

df[df["status"].str.contains("pa", na=False)]

我几乎在所有str.contains调用上都固定带上na=False，因为这个参数默认值带来的报错太常见了，而且报错信息完全没提"缺失值"三个字。

第三个要注意的是大小写。case=False可以忽略大小写，比手动str.lower()再匹配更简洁，也不会产生中间列。中文场景没有大小写问题，但中英文混合、或者英文状态码（paid/PAID/Paid）混用时，这个参数很值。

5.4str.match与str.startswith的区别

contains是"包含"，match是"从开头匹配"，startswith是"前缀匹配"。三者的差别在加了正则锚点后更明显：

s = pd.Series(["paid_2024", "unpaid_2024", "2024_paid"]) s.str.contains("paid") # 三个全中 s.str.match("paid") # 只有第一个（从开头开始匹配） s.str.startswith("paid") # 只有第一个（纯字符串前缀，不走正则）

match走正则、从开头匹配；startswith不走正则、只比字面前缀。性能上startswith更快，语义上更明确。如果只是判断前缀，优先用它，不要为了"显得专业"而套正则。

顺带提一句str.extract，它不是筛选但经常和筛选连着用：先用正则抽出一个片段生成新列，再对新列做条件筛选，比先筛后拆要少一步中间判断。比如从订单号里抽出渠道编码，再据此过滤，这个组合我在日志分析里用得最多。

6. 缺失值与类型：筛选结果不对的两大隐形来源

6.1NaN比较永远为 False

这是所有"条件明明写了却筛不出数据"问题里排名第一的原因。NaN在浮点语义里表示"不是一个确定的数"，任何和它比较的结果都是 False：

np.nan > 0 # False np.nan < 0 # False np.nan == np.nan # False

所以df[df["amount"] > 0]这条筛选，会同时排除掉金额为负的行和金额为 NaN 的行。多数时候这正是你想要的，但如果你需要保留空值、只是排除非正值，就得显式处理：

df[(df["amount"] > 0) | df["amount"].isna()]

判断缺失必须用isna()/notna()，不能用== np.nan。这个方法对None、np.nan、pd.NaT都返回 True，是唯一可靠的通用判断。

6.2isna/notna与dropna的subset

整行含空就删，用dropna()；只看某几列为空才删，用subset：

df.dropna(subset=["amount", "status"]) # 这两列为空才删 df.dropna(subset=["amount"], thresh=1) # 保留至少一个非空的 df.dropna(how="all") # 整行全空才删

默认的dropna()是"任一列为空就删"，这在宽表上很危险——一张 50 列的表，只要有一个字段偶尔缺失，能删掉大半数据。我踩过一次：做用户行为分析，dropna()之后剩不到三成，查了很久才发现是某个几乎全空的埋点字段在起作用。

thresh参数也常被忽略。df.dropna(thresh=n)的含义是"非空值数量少于 n 的行才删"，注意是非空值的个数而不是某个具体值。想表达"至少有 3 个字段有值"，就该用thresh=3。

6.3 数字被存成字符串

read_csv读进来，amount列如果混进了 "N/A"、"待定"、空字符串，整列会被推断成object。这时候df["amount"] > 100会抛TypeError: '>' not supported between instances of 'str' and 'int'，或者更糟——在全部是数字字符串时，它按字典序比较：

"9" > "100" # True，因为字符串比较逐位看字符

这个结果不会报错，但完全错误。判断方法很简单，读进来先跑一遍：

df.dtypes df["amount"].apply(type).value_counts()

只要看到object出现在本该是数值的列上，先转换再筛选，不要急着写条件。转换时用pd.to_numeric(df["amount"], errors="coerce")，把转换失败的变成NaN，这样既能筛出坏数据在哪里，又不会让整列失败。

6.4 日期列的字符串比较

和上一节同源的问题。created列如果是字符串，between("2024-01-05", "2024-01-20")能"看起来正确"，纯属标准格式下的巧合。一旦遇到"2024-1-5"这种不补零的写法，字典序比较立刻失效——"2024-1-5"按字符串比是大于"2024-01-20"的，因为"1" > "0"。

所以拿到日期列，第一件事永远是：

df["created"] = pd.to_datetime(df["created"], errors="coerce")

errors="coerce"把解析失败的值变成NaT，然后你可以专门筛出来看：df[df["created"].isna()]。这比直接报错中断要友好得多，尤其在做批量数据清洗的时候。

注意：NaT和NaN一样，参与任何比较都返回 False，所以df[df["created"] > "2024-01-01"]会安静地排除掉所有解析失败的记录。定期统计一下df["created"].isna().sum()是个好习惯。

7. 筛选之后：链式索引、性能与可复现

7.1SettingWithCopyWarning的来龙去脉

筛选之后改值，是这个警告最常出没的地方：

sub = df[df["amount"] > 100] sub["flag"] = 1 # SettingWithCopyWarning df[df["amount"] > 100]["flag"] = 1 # 静默失败，df 根本没变

第二行更危险——它不报错，也不改原表，你以为改了，实际上改的是一个临时对象。原因是df[mask]返回的是副本还是视图不确定，Pandas无法判断，只能给警告；而链式索引（连续两次[]）中的赋值，目标是一闪而过的临时对象，赋值直接丢失。

正确写法是 ONE 步赋值，明确告诉Pandas你要改哪张表的哪几行的哪一列：

df.loc[df["amount"] > 100, "flag"] = 1

如果确实想让sub成为独立副本、后续随便改，就显式copy()：

sub = df[df["amount"] > 100].copy() sub["flag"] = 1

我的经验是：只要筛选结果需要修改，一律.copy()或者用.loc一步到位，不要赌Pandas的推断。这个警告在Pandas2.x 里还引入了 Copy-on-Write 模式的开关，行为会进一步收紧，早点养成习惯没坏处。

7.2 大表下几种写法的耗时对比

我在一台普通笔记本上做过一轮粗略测试，数据量 200 万行、8 列，条件为"区域在 A/B 且金额大于 100 且状态为 paid"，每种写法跑 20 次取中位数：

结论不必过度解读——在几十万行以下，几种写法都在百毫秒量级，选可读性最好的那个。真到性能瓶颈时，先考虑减少数据量（只读需要的列usecols、把过滤下推到读取阶段read_csv的chunksize），再考虑换写法。先优化 IO 和数据量，再优化表达式，这是我踩过几次坑之后定下的顺序。

7.3 mask 复用与索引重置

条件复用是提升代码质量的一个小技巧。把常用的筛选条件存成有名字的变量：

is_paid = df["status"] == "paid" is_valid_amount = df["amount"].between(0, 10000, inclusive="both") paid_valid = df[is_paid & is_valid_amount] refund_valid = df[~is_paid & is_valid_amount]

好处有三：一是条件语义被命名了，读代码的人不用逐字解析；二是同一个条件在多处使用时不会写错；三是调试时可以直接print(is_paid.sum())看命中多少行，比对着结果表猜要快得多。

索引重置的时机则要看下游。如果筛选结果要直接导出成 CSV，重置一下更干净；如果要和原表做关联（merge / join），保留原索引有用；如果要按位置往后取iloc，重置能避免混淆。我一般的规则是：只做展示和导出时reset_index(drop=True)，中间过程不重置。

final = df[is_paid & is_valid_amount].reset_index(drop=True)

顺带说个反面案例：有人在筛选后reset_index(drop=True)，然后又拿这个新表去和原表按索引merge，结果全错位。索引看起来只是个编号，但它是表的"身份"，动之前想清楚有没有下游依赖。

7.4 把筛选条件参数化

最后一个我觉得很实用的做法：把筛选条件从硬编码改成参数，尤其是当你需要反复跑相似但不相同的筛选时。

def filter_orders(df, regions=None, min_amount=None, status=None, date_range=None): cond = pd.Series(True, index=df.index) if regions is not None: cond &= df["region"].isin(regions) if min_amount is not None: cond &= df["amount"] >= min_amount if status is not None: cond &= df["status"].isin(status) if date_range is not None: start, end = date_range cond &= df["created"].between(start, end, inclusive="left") return df[cond].copy() filter_orders(df, regions=["区域A"], min_amount=100, status=["paid"])

这里有个关键点：初始条件用pd.Series(True, index=df.index)而不是True，是为了让后续的&=始终在同索引的 Series 之间运算。如果初始值写成True，第一次True & series虽然也能得到正确结果，但第二次就容易出类型问题，而且显式构造能保证长度和索引一致。

这种写法把"条件拼装"和"数据筛选"分开了，调用方只关心传什么参数，不用管布尔运算怎么写。我在做周期性报表时用这套结构，几个固定筛选条件组合出十几种视图，改需求时只需要动参数。

最后再分享一个小技巧：筛选完之后如果对结果的数量有预期，加一句assert len(result) > 0，能在数据源异常时第一时间暴露，而不是等到下游画图时才崩。断言在生产代码里可以去掉，但在探索阶段非常有用。