pd.merge() 默认为内连接，但必须显式指定 how 参数（如 how='inner'）以避免协作或阅读时出错；key列需dtype一致且列名明确匹配，多列合并用列表，复杂条件需预处理，同名列会自动加_x/_y后缀引发隐患。
merge() 默认是内连接，但得手动指定 how 参数才安全
很多人以为 pd.merge() 不写 how 就是内连接，确实默认值是 'inner'，但靠默认值容易翻车——比如团队协作时别人改了默认行为（虽然 Pandas 不会这么干），或者自己看代码时漏读参数。实际用的时候，how='inner'、how='left' 这些必须显式写出来。
常见错误现象：merge() 后行数比预期少，发现右表某些 key 在左表不存在，却没意识到这是内连接的天然行为；或者想保留左表全部记录，却忘了加 how='left'，结果默默变成内连接。
-
how='inner'：只保留左右表 key 都存在的行，等价于 SQL 的INNER JOIN -
how='left'：以左表为基准，右表匹配不上就填NaN，等价于 SQL 的LEFT JOIN -
how='right'和how='outer'也同理，但用得少；outer是全外连接，SQL 里要写FULL OUTER JOIN
on、left_on、right_on 容易配错列名或类型
合并失败最常见的原因是 key 列“看着一样，其实不能对上”。比如左表的 user_id 是字符串，右表的 id 是整数；或者两边都有 name 列，但拼写不一致（'Name' vs 'name'）；又或者用了 on 却没确认两表是否有同名列。
使用场景：当左右表 join key 列名相同时，用 on='col_name' 最简洁；名字不同时，必须拆开用 left_on='left_col' 和 right_on='right_col'。
立即学习“Python免费学习笔记（深入）”；
- 别依赖
on自动推断——Pandas 不会猜你哪列该对齐，它只认你写的列名 - 合并前先检查
df1['key'].dtype和df2['key'].dtype，字符串统一用.astype(str)，数值统一用.astype(int) - 如果 key 是多列，传列表：
on=['col_a', 'col_b']，注意两边列顺序和含义要严格对应
merge() 没有 SQL 的 ON 条件扩展能力，复杂逻辑得先预处理
SQL 可以写 ON a.x = b.y AND b.status != 'deleted'，但 pd.merge() 的 on / left_on 只支持等值匹配，不支持不等式、函数或布尔表达式。想实现类似效果，得把条件挪到 merge 前后。
性能影响明显：在大表上先 query() 过滤再 merge，比 merge 完再 query() 快得多，因为减少了中间结果集大小。
- 想过滤右表再 join？先
df_right_filtered = df_right.query("status != 'deleted'")，再 merge - 想做范围 join（比如时间区间匹配）？
merge()不行，得用pd.merge_asof()或手动cross join + query（慎用，爆炸性增长） - 需要多条件等值（如 A=B 且 C=D）？确保这两对列都放进
on=[...]列表，不要试图在on里写表达式
重复列名会自动加 _x / _y 后缀，但容易漏查冲突
如果左右表都有 name、score 这类同名列，merge() 默认会给它们加上 _x（左表）和 _y（右表）后缀。这看起来方便，但问题在于：你可能根本没意识到某列被重命名了，后续代码还硬写 df['score']，结果报 KeyError。
兼容性影响：下游如果依赖固定列名（比如导出到数据库或传给另一个函数），这种自动改名就是隐患。
- 用
suffixes=('_left', '_right')显式控制后缀，比默认的_x/_y更可读 - 合并后立刻检查
result.columns，尤其关注是否出现意料之外的_x或_y - 如果确定只要某一边的列，合并前先
select掉另一侧的同名列，比如df_right = df_right.drop(columns=['name'])
