合并后行数暴增源于键重复导致的笛卡尔发散，如左表某key出现100次、右表对应key出现200次，仅此一组就产出2万行；需用groupby.size().describe()查重复分布，is_unique验证键唯一性，并显式设置validate="1:1"触发错误拦截，合并后加.copy()切断引用链防内存泄漏。
合并操作本身不暴增内存，暴增的是结果行数——一对多发散会让输出行数远超输入总和，这是最常被忽略的根源。
merge 或 join 后 len(df) 突然翻几十倍？先查键的唯一性
Pandas 的 merge 默认是 inner/outer/left/right 连接，只要左表或右表的连接键存在重复值，就会触发笛卡尔式发散。比如左表 10 万行、右表 5 万行，但左表某 key 出现 100 次、右表对应 key 出现 200 次，仅这一组匹配就产出 2 万行——远超原始规模。
- 用
df.groupby("key").size().describe()快速看连接键的重复分布，重点关注max值是否远大于 1 - 对左右表分别运行
df["key"].is_unique，任一为False就需警惕 - 不要只看“有没有重复”，要看“重复集中在哪些 key 上”——用
value_counts().head(10)定位高频发散源
pd.merge(..., validate="m:1") 不报错？说明你没开验证
validate 参数不是默认开启的，它只在显式传入时才起作用。很多人误以为加了参数就安全，其实漏写或拼错（如写成 validation）等于没设。
- 合法值只有
"one_to_one"、"one_to_many"、"many_to_one"、"many_to_many" - 想强制要求左键唯一且右键唯一，必须写
validate="1:1"（注意是字符串"1:1"，不是数字） - 若实际数据不满足却强行指定
"1:1"，会抛出MergeError，这才是你想要的失败信号
发散后 DataFrame 内存为何“下不去”？因为视图引用未断
合并结果如果被赋值给变量、又参与后续 groupby 或 assign，Pandas 可能保留对原始块的引用（尤其是使用 copy=False 时），导致即使删掉中间变量，内存也不释放。
立即学习“Python免费学习笔记（深入）”；
- 确认是否真释放：执行
del merged_df后，立刻调用gc.collect()，再观察psutil.Process().memory_info().rss - 保险做法：合并后立即加
.copy()，切断与上游的隐式引用链，哪怕多花一点内存也比泄漏强 - 检查是否有
df.iloc[...]或df.loc[...]切片后直接用于 merge —— 这类视图可能拖住整个原始 DataFrame
真正危险的不是“合并慢”，而是“合并完看不出异常，但内存悄悄涨到 OOM”。发散行数和引用残留这两点，一个影响数据逻辑正确性，一个影响资源稳定性，缺一不可验。
