布尔索引比query()更快，因其跳过字符串解析和Python解释器开销；query()易因反引号缺失、引号混淆、and/or误用、括号优先级错误等出错；性能敏感场景应按使用场景选择：探索分析用query()，高频调用或固定逻辑用布尔索引。
布尔索引为什么比 query() 更快
直接用布尔索引（比如 df[df['age'] > 25]）通常比 df.query("age > 25") 快，因为跳过了字符串解析和 Python 解释器的额外开销。尤其在小到中等数据量（
- 布尔索引走的是 NumPy 底层向量化路径，
query()要先 parse 字符串、构建表达式树、再执行 -
query()在列名含空格、特殊字符或变量插值时更方便，但代价是启动慢 - 如果条件里要引用外部变量，布尔索引写
df[df['x'] > threshold]更直观；query()得写df.query("x > @threshold")，漏掉@就报NameError: name 'threshold' is not defined
query() 的字符串语法容易踩哪些坑
query() 看似简洁，但它的字符串上下文和隐式规则常导致意外行为。
- 列名含空格或点号（如
"user name"或"user.email"）必须用反引号包裹：df.query("`user name` > 30") - 字符串值要用单引号（
'abc'），双引号在 f-string 中易冲突；写成f"col == {val}"且val是字符串时，极易生成不合法表达式 -
and/or是关键字，不能用&/|；写df.query("a > 1 and b 对，但 <code>df.query("a > 1 & b 会因运算符优先级错报错 - 对缺失值判断别写
col == None，得用col.isnull()或col != col（后者在query()里有效）
多条件组合时布尔索引怎么避免括号错误
用 &、|、~ 拼条件时，每个子表达式**必须用圆括号包裹**，否则会因运算符优先级出错——这是最常被忽略的语法雷区。
- 错：
df[df.a > 1 & df.b → 报 <code>ValueError: The truth value of a Series is ambiguous - 对：
df[(df.a > 1) & (df.b - 混合
&和|时，括号不能省：df[(df.x == 'A') & (df.y > 10) | (df.z == 'B')]逻辑不对，应为df[((df.x == 'A') & (df.y > 10)) | (df.z == 'B')] - 用
isin()替代多个==或判断更清晰：df[df.city.isin(['Beijing', 'Shanghai'])]
性能敏感场景下该选哪个方法
不是“哪个更好”，而是“哪个更合适”——取决于你正在写的代码位置和迭代频率。
立即学习“Python免费学习笔记（深入）”；
- 一次性探索分析（Jupyter 里临时查几行）：用
query()，少打字、可读性高，慢几十毫秒无所谓 - 封装成函数反复调用、或进 pipeline 流水线：优先布尔索引，尤其当条件逻辑固定、列名合规时
- 列名动态生成（比如从配置读取字段名）：
query()插值更安全，布尔索引得用df.loc[:, col_name]+df[col_name] > x组合，稍啰嗦但可控 - 内存受限时注意：
query()内部会复制部分中间结构，大数据集上比布尔索引略吃内存
真正麻烦的是混用两种风格又没统一处理缺失值逻辑——比如布尔索引默认跳过 NaN 比较（结果为 False），而 query() 的 == 对 NaN 也返回 False，但 isin() 行为一致。这点不细看日志很难发现。
