面试官最常考的pandas操作是按条件筛选、分组聚合、关联合并三类，核心是还原SQL逻辑：query替代布尔索引提升可读性，groupby.agg优先于apply，merge需显式指定how='left'并设suffixes，filter对应HAVING但需返回布尔值，注意NULL处理与reset_index。
面试官最常考的 pandas 操作，其实就这三类
不是考你背函数，是看你能不能用 pandas 快速还原 SQL 里的核心逻辑。面试中出现频率最高的是：按条件筛选 + 分组聚合 + 关联合并。这三类操作一旦写错，基本就暴露了“只调过包、没理清数据流”。
实操建议：
-
df.query()比布尔索引更贴近 SQL 的可读性，但注意它不支持列名含空格或特殊字符（得用df.query("`col name` == 'x'")） - 分组聚合优先用
df.groupby().agg()，别堆df.groupby().apply(lambda x: ...)—— 面试官一眼看出你不会向量化 - 合并时默认
how='inner'，但实际业务多是左连接，务必显式写how='left'，否则线上跑通、面试挂掉
pd.merge() 和 SQL JOIN 对不上？先看这几个参数差异
很多人写完 pd.merge() 结果行数爆炸或变少，不是数据问题，是没对齐 SQL 里的 ON 和 WHERE 语义。
常见错误现象：merge 后出现重复行，或丢失本该保留的左表记录。
立即学习“Python免费学习笔记（深入）”；
实操建议：
-
on只负责匹配字段，不等价于 SQL 的ON+WHERE；过滤必须拆到 merge 前或后，不能塞进on -
suffixes=('_left', '_right')必须设，尤其当两表有同名列——否则merge后列名自动变成col_x/col_y，后续代码全崩 - 想模拟
LEFT JOIN ... AND condition？得先merge，再用df.loc[condition]过滤右表部分行，merge本身不支持 on+and
SQL 里 GROUP BY + HAVING，pandas 怎么写才不绕弯
df.groupby().filter() 是唯一能直接对应 HAVING 的方法，但多数人卡在“不知道 filter 接的是布尔 Series 而不是标量”。
使用场景：筛选出订单数 > 5 的用户、平均分
实操建议：
-
filter(lambda x: x['amount'].sum() > 100)是错的——x是每个分组的子 DataFrame，x['amount'].sum()才是标量，但 filter 要求返回 True/False，不是数值 - 正确写法：
df.groupby('user_id').filter(lambda g: g['order_id'].count() > 5) - 性能影响：filter 会遍历所有分组，大数据量时比先聚合再布尔索引慢；若只是要聚合结果，用
agg+query更快（df.groupby().agg(...).query('count > 5')）
面试写 SQL 等价代码，最容易被忽略的其实是索引和缺失值处理
SQL 默认忽略 NULL 参与聚合（COUNT(col) 不计空值，SUM 自动跳过），但 pandas 的 count() 默认统计非空，sum() 却会把整列变 NaN —— 这个差异一不留神就导致结果对不上。
实操建议：
- 用
df['col'].sum(skipna=True)（默认就是 True，但显式写出更稳妥）；如果字段是字符串型数字，先pd.to_numeric(..., errors='coerce')，否则sum()直接报错 - groupby 后若某组全为 NaN，
agg('sum')返回 NaN，而 SQL 的SUM返回 NULL —— 表面一致，但后续fillna(0)或dropna()动作必须明确，不能依赖默认行为 - 别忘了 reset_index()：SQL 返回的是普通表，
pandasgroupby 默认返回 MultiIndex，不重置的话，后续merge或query全部失效
真正卡人的从来不是语法，而是 merge 前没 drop duplicates、groupby 后忘了 reset_index、或者用 count() 代替 size() 导致空组被漏掉——这些细节，查文档都找不到，只能踩过才记得住。
