eval适合列间算术运算且性能优于普通Python运算，但字符串解析有开销；query专用于条件过滤，不支持赋值，二者均依赖numexpr引擎提速。
eval 适合做列间算术运算，但字符串表达式有开销
eval 在 Pandas 中主要用于动态执行列参与的算术或逻辑表达式，比如 df.eval("C = A + B")。它比普通 Python 运算快，因为底层调用的是 numexpr，能自动并行和避免中间数组创建。
但要注意：每次调用 eval 都要解析字符串，如果循环中反复用 df.eval("A > 0") 判断，反而比直接写 df["A"] > 0 慢。真正受益的场景是——一次计算多个列、含重复子表达式（如 df.eval("X = A*B + A*C")，numexpr 会复用 A 的加载）。
- 支持的运算符有限，不支持自定义函数（如
np.log要显式注册或改用engine="python"，但性能下降） -
engine="numexpr"（默认）更快，但不支持某些 Python 语法（如三元表达式x if cond else y） - 涉及字符串操作（如
"col.str.contains('x')"）时，eval不支持，必须用原生链式调用
query 更适合条件过滤，但不能修改原 DataFrame
query 是为布尔筛选设计的，语法简洁，例如 df.query("A > 10 and B in @my_list")。它同样走 numexpr 引擎，对大 DataFrame 过滤比 df[df["A"] > 10] 略快，尤其当条件复杂、涉及多列时。
关键限制是：它只返回新视图/副本，无法就地赋值或新增列。想边查边改？不行。比如 df.query("A > 10").assign(C=lambda x: x.A * 2) 看似连贯，但 query 已触发一次拷贝，后续 assign 又是一次，不如先 mask = df["A"] > 10 再用布尔索引切片加计算。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
@符号引用外部变量（如列表、标量），但不能引用 DataFrame 列名以外的局部变量（比如循环里的i，得写成@i） - 列名含空格或特殊字符时，必须用反引号包裹：
df.query("`col name` > 0") - 对小 DataFrame（query 的解析开销可能抵消加速收益，实测未必更快
eval 和 query 组合使用容易踩内存坑
有人习惯先 df.eval("flag = A > B", inplace=True) 再 df.query("flag")，以为能复用中间列。问题在于：eval 默认返回新 DataFrame 或 Series，即使设了 inplace=True，也仅对新增列生效；而 query 总是返回副本——两次操作都触发拷贝，内存翻倍。
更稳的写法是单次完成：用 eval 计算条件表达式，直接喂给布尔索引：df[df.eval("A > B and C 。这样只产生一个布尔数组，不落地中间列。
- 避免在链式调用里混用：
df.eval(...).query(...)会强制生成中间结果，失去流式处理优势 - 如果真需要临时列参与多次查询，先用
df.assign(temp=...)创建，再用原生布尔索引，比反复eval+query更可控 - 注意
eval和query对缺失值的处理和pd.NA兼容性较差，遇到 nullable 类型列（如Int64）建议降级用原生布尔运算
真实提速要看数据规模和表达式复杂度
别盲目替换。在 100 万行以下、条件简单的场景，df["A"] > 10 & df["B"].isin([...]) 和 df.query("A > 10 and B in @vals") 性能差异常小于 10%，但可读性可能更好；而百万级以上、含 sin/log 等逐元素函数时，eval 才显出价值。
验证方法很简单：用 %timeit 对比，且确保测试时 DataFrame 已加载进内存（避免 IO 干扰）。特别留意——如果你的瓶颈在磁盘读取或网络请求，优化 eval 毫无意义。
- 开启
pd.options.mode.chained_assignment = None避免 SettingWithCopyWarning 干扰计时 - numexpr 默认线程数等于 CPU 核心数，但高并发环境下可能需手动设
numexpr.set_num_threads(2)防止争抢 - PyArrow backend（Pandas 2.0+）下
eval/query支持有限，部分表达式会退回到 Python 引擎，速度反降
实际用的时候，先想清楚：这是不是 CPU-bound 操作？表达式是否足够重？有没有被隐式拷贝拖慢？这些比记住语法更重要。
