1. 为什么说合并数据是 Pandas 中最容易“掉坑”的操作

在 Pandas 的日常使用里，pd.concat和pd.merge可能是出现频率最高的两个函数。很多人对它们的理解停留在“一个用来上下拼接，一个用来按列匹配”，但实际用下来却经常被各种怪问题折磨——明明数据看起来差不多，合并结果却多出一堆重复行；明明索引对得上，concat却给你生成了一堆NaN；明明两个表都干干净净，merge之后内存直接爆掉。

我做数据分析这十几年，几乎每周都会在社区或同事的代码里看到类似的困惑。老实说，这些问题绝大多数不是函数本身出了 bug，而是我们对 Pandas 合并 API 的设计逻辑理解得不够透彻。Pandas 提供concat、merge、join、combine_first等一系列看似功能重叠的接口，背后其实是一套相当清晰的设计哲学：每种操作对应一个“数据拼装”的语义场景，选错 API 或者用错参数，轻则结果不对，重则性能雪崩。

这篇文章我不打算只是罗列几个示例然后说“这个能拼、那个能连”，而是想从设计源头把合并 API 拆开来讲清楚：为什么 Pandas 要设计这么多合并函数，它们的边界在哪，高阶场景下怎么选型，以及我踩过的一些坑和排查思路。不管你是刚接触 Pandas 的新手，还是写了很多年数据处理的老手，我相信都能在里面找到一些值得琢磨的东西。

2. 从“怎么拼数据”到“为什么这么拼”：Pandas 合并 API 的设计哲学

2.1 数据合并的三个底层语义：对齐、连接与迭代

要理解 Pandas 的合并 API，先要跳出函数本身，回到数据拼接的本质。任何一次数据合并，底层都逃不开三个问题：数据在哪个方向上拼接？依据什么条件匹配？匹配不上的部分怎么处理？Pandas 把这几个问题拆解成了不同的 API，而不是像有些工具那样一个函数打天下，这就是它的设计哲学所在。

pd.concat解决的是“轴向拼接”问题——你可以把它理解成把几沓纸按顺序叠起来或者并排铺开。它不关心两张表的内容是否有关联关系，只关心你要不要把它们放在同一个 DataFrame 里继续处理。所以concat的核心逻辑是“对齐轴”（通常是 index 或 columns），而不是“匹配数据”。

pd.merge解决的则是“关系连接”问题——类似 SQL 中的 JOIN，它关注的是一张表的 key 如何在另一张表中找到对应的行。这种操作天然带有集合论的味道：内连接、外连接、左连接、右连接，本质上是数学上的交集、并集和差集。

这两个 API 看起来好像都在“合并数据”，但实际上服务的是两种完全不同的需求。很多人出错，正是因为把对齐当成了匹配，或者把匹配当成了对齐。

2.2 为什么有了 merge 还需要 concat：合并的对象完全不同

一个常见的误区是认为merge是concat的“高级版”。真不是这样。这两者的区别，用一句话概括就是：concat合并的是“结构相同或相似”的数据，merge合并的是“键相同但结构互补”的数据。

举一个生活中的例子。假设你手上有两份名单：一份是 2023 年销售冠军名单，一份是 2024 年销售冠军名单。你想把两年的名单放在一起做一个总表，这时候用concat就很自然——它们行数不同、内容不同，但列结构完全一样，你要做的只是把第二个 DataFrame 接到第一个下面。反过来，如果你手上有一份员工基本信息表，和一份每个员工对应的业绩表，两份表的列完全不同，但都包含“员工编号”这一列，你想把两边的信息合并到一张表里，这时候就该用merge——它是按员工编号去“对齐”行，然后把两边的列拼到一起。

顺着这个思路往下走，你会自然地发现一个更深层的问题：concat只要求“轴向结构一致”，而merge要求“键的值能对上”。操作意图完全不同，API 自然也就不能互相替代。Pandas 在设计上遵循的就是“一个函数对应一种聚合语义”的理念，搞清楚自己当前要的是哪种语义，比死记参数要有效得多。

2.3 数据合并不是一个动作，而是一整套操作族

Pandas 里的合并 API 其实是一个操作族。除了大家最熟悉的concat和merge，还有 DataFrame 自带的join方法（本质上是 merge 的特化场景）、combine_first（用一张表填充另一张表的缺失值）、update（原地修改部分数据）、compare（对比差异）等。

我见过不少资深数据分析师也未必能把每个函数都叫得上名，但实际上这些操作之间是有脉络的：join是“按索引合并”的便捷入口，combine_first是“位置对齐后补缺失”的合并，update则是“位置对齐后覆盖非缺失值”的合并。它们都基于同一个底层的对齐机制，却在面向的场景上做了细分。设计上的这种“细分”带来的好处是：读者看到你的代码，能通过你用的函数一眼知道你当时的处理意图。代码的意图表达力，本身就是一种生产力。

所以在正式展开concat和merge之前，我想先立一个结论：合并 API 的选择，首先不是性能问题，而是语义问题。把语义选对了，后面的参数配置才是顺水推舟的事。

3. pd.concat 与 pd.merge 核心差异：什么时候用哪个

3.1 pd.concat 的完整机制：不止是“直接拼起来”

pd.concat最基础的用法是把多个 DataFrame 按行堆叠，一行代码就能完成。但你真的理解它在堆叠时做了什么吗？我拆开来说。

import pandas as pd df1 = pd.DataFrame({"id": [1, 2], "value": ["a", "b"]}) df2 = pd.DataFrame({"id": [3, 4], "value": ["c", "d"]}) pd.concat([df1, df2])

上面这段的结果是得到一个 4 行 2 列的表，这没问题。但如果你把df2的列名改一下，比如把"value"改成"score"，再用同样的代码呢？结果会变成一个 4 行 3 列的表，多出来的一列全是NaN。因为concat在默认参数join='outer'下，会对轴对齐做“并集”——列名对不上的部分用缺失值填充。

这个行为对新手来说经常是“惊喜”，但它其实是精心设计的。Pandas 认为，你在做轴向拼接时，可能遇到结构不完全一致的数据（比如不同月份的报表字段有小差异），与其直接报错，不如保留所有列信息，让你自己决定怎么处理。

如果你想严格一点，只保留两边都有的列，把join='inner'就行：

pd.concat([df1, df2], join='inner')

还有一个容易忽略的参数是ignore_index。很多时候我们并不关心拼接后每一行原来的索引是什么，尤其是在做批量文件读取再合并的场景。如果不设ignore_index=True，结果 DataFrame 的索引可能是一段 0 1 0 1 这样重复的序列，后续做loc或者reset_index都会很别扭。

pd.concat([df1, df2], ignore_index=True)

这样索引就会重新变成 0 1 2 3，干干净净。

3.2 pd.merge 的匹配逻辑：键、连接方式和多键合并

merge的设计核心是“键”。它不像concat那样按轴位置或名称对齐，而是按你指定的列（或索引）的值去匹配行。

left = pd.DataFrame({"key": ["A", "B", "C"], "left_value": [1, 2, 3]}) right = pd.DataFrame({"key": ["B", "C", "D"], "right_value": [4, 5, 6]}) pd.merge(left, right, on="key")

默认how='inner'，结果是：

只保留能匹配上的行，这就是内连接。

如果你想要保留 left 中所有行，不管它能不能在 right 中找到对应值，用how='left'。同理，how='right'保留 right 的所有行，how='outer'保留两边的所有行，匹配不上的部分填充为NaN。

这里有个值得细说的点：当 left 或 right 中的 key 存在重复值时，merge会产生笛卡尔积式的行爆炸。比如 left 中 A 出现两次，right 中 A 出现三次，合并后 A 的行数就是 2×3=6 行。这个概念非常重要，因为在数据清洗场景中，key 的重复是常态，而一旦你忽略了这一点，结果表的行数会莫名其妙地暴涨，排查起来相当费劲。

left = pd.DataFrame({"key": ["A", "A", "B"], "left_value": [1, 2, 3]}) right = pd.DataFrame({"key": ["A", "A", "A", "B"], "right_value": [10, 20, 30, 40]}) pd.merge(left, right, on="key")

这个结果会有 2×3+1=7 行。如果你没有在合并前确认 key 的唯一性，这个行为会直接带偏后续所有的统计结果。

3.3 一张表理清 concat 与 merge 的选型

我把它们的差异整理成了一张对照表，方便你在实际中快速做判断。

选型的判断口诀很简单：结构相加用concat，字段互补用merge。如果你是要把几个月的数据文件读进来合成一个大表，concat就够了；如果你要做的是维表映射、明细表关联，绕不开merge。

4. 高阶实践一：索引合并与多级索引的坑

4.1 join 方法与 merge 的关系：索引就是隐藏的 key

DataFrame 自带的join方法，本质上是merge的一种便捷形式，但它有一个非常鲜明的特点——默认按索引匹配，而不是按列匹配。也就是说，join是merge的“索引接口”。

df1 = pd.DataFrame({"value1": [1, 2]}, index=["a", "b"]) df2 = pd.DataFrame({"value2": [3, 4]}, index=["a", "c"]) df1.join(df2)

上面这段代码的结果是：

因为索引 a 在两边都有，而 b 只在 df1 中，c 只在 df2 中，默认左连接时 b 行的 value2 就是 NaN。

为什么这个设计值得重视？因为在很多真实业务里，时间序列数据或者按某种结构化标签组织的数据，索引本身就是业务键。比如你有一批按日期为索引的指标数据，想和另一批同样按日期为索引的元数据合并，用join会比先 reset_index 再 merge 干净得多，而且省去了一次不必要的索引重置操作。

但join也有个容易踩的坑：当两边索引不是唯一值时，它同样会产生笛卡尔积，而且因为索引重复往往更隐蔽，更容易让人忽略验证。

4.2 多级索引（MultiIndex）的合并细节

多级索引的合并是我在实际项目中反复打磨过的一个场景。如果你有两个 DataFrame，索引都是两层（比如“城市”+“日期”），想对这两层索引做合并，merge要专门指定on为多层索引名，join则要配合on参数使用。

left = pd.DataFrame( {"value": [1, 2, 3]}, index=pd.MultiIndex.from_tuples([("北京", "2024-01-01"), ("北京", "2024-01-02"), ("上海", "2024-01-01")]) ) right = pd.DataFrame( {"score": [10, 20, 30]}, index=pd.MultiIndex.from_tuples([("北京", "2024-01-01"), ("上海", "2024-01-01"), ("上海", "2024-01-02")]) ) left.join(right)

上面的例子中，只有当两个 DataFrame 的 MultiIndex 层级命名和顺序完全一致时，join才能直接生效。否则你要么先reset_index()把 MultiIndex 变成普通列再 merge，要么显式指定on参数。

实操心得：我在处理带时间维度的数据时，更倾向于先 reset_index 再 merge，而不是强行用 MultiIndex 对齐。原因很简单：reset 之后 key 变成普通列，后续做筛选、分组、透视都更方便，而且踩坑概率显著降低。多级索引让数据在直观上更紧凑，但代价是很多操作符的行为会变得隐晦，调试成本上涨。如果只是临时用一次索引做 merge，那没问题；一旦数据要经过多步处理，我的建议是尽早把索引降维成普通列。

4.3 合并后索引失序的处理技巧

merge之后，结果 DataFrame 的索引默认是 0 到 n-1 的整数序列，但如果你使用了join或者合并时指定了某些 index 参数，索引可能变得混乱。很多人喜欢立刻执行reset_index(drop=True)，把隐藏的索引包袱彻底丢掉。

其实这里有个更省事的习惯：如果你确定合并后不想保留任何索引信息，直接在merge之前就把两边的索引 reset 掉，然后只用普通列作为on的 key。这套流程非常机械，但不容易出错。我见过太多人把索引留着，merge 之后索引列和业务列混在一起，后续还要小心翼翼地选列。与其纠结，不如一开始就“索引归索引、列归列”地整理好。

5. 高阶实践二：列冲突、重复列与 validate 校验

5.1 suffixes 参数：合并后列名冲突的艺术

merge有一个让人又爱又恨的行为：如果左右两个 DataFrame 除了 key 之外，还有其他同名但不相同的列，合并后这些列会被自动加上_x和_y后缀。这就是suffixes参数的默认值('_x', '_y')。

left = pd.DataFrame({"key": [1, 2], "value": [10, 20]}) right = pd.DataFrame({"key": [1, 2], "value": [100, 200]}) pd.merge(left, right, on="key")

结果会变成value_x和value_y。这本身很合理，但实际工作中，列名冲突往往不止发生在“value”这种泛化名字上，还可能发生在“amount”“count”“score”等一堆业务字段上。如果你不提前规划，合并出来的表会有一堆_x和_y后缀，读起来非常痛苦。

我的建议分两步走：

第一，在合并前明确要保留哪些列，通过left.columns和right.columns的差集来判断是否会产生冲突。

第二，用suffixes参数主动给冲突列命名，比如：

pd.merge(left, right, on="key", suffixes=("_计划", "_实际"))

第三，如果列特别多，或者冲突很严重，干脆把其中一方的业务列 rename 掉再合并。比如销售数据里，把 A 表的amount改成amount_2023，B 表的amount改成amount_2024，合并后直接就是带年份的区分名。这个方案在结果清晰度上是最优的。

5.2 validate 参数：你与数据质量之间的一道保险丝

validate可能是 Pandas 合并 API 中最被低估的参数。它能帮你校验合并前后 key 的基数关系，在数据质量检验环节中相当于一道保险丝。

pd.merge(left, right, on="key", validate="one_to_one")

可选的参数值有：

我在实际项目中几乎每次 merge 都会带上 validate 参数，除非我明确知道本次合并就是 many_to_many 关系。这不是强迫症，而是因为 merge 的笛卡尔积效应太隐蔽了——如果你不做校验，一个重复 key 就能让结果行数翻几倍，而且这种错误往往不会报错，只会默默地污染你后续所有统计结果。加了 validate，等于让 Pandas 在合并前帮你做一次数据质量断言，任何意外重复都会立刻 expose 出来。

一个真实的教训：我曾经处理过一个用户点击日志表和用户信息表的合并，因为日志表的 user_id 天生就是重复的，结果跑出来的结果比预期多了几十万行。排查了几个小时，最终定位到是底层表里 user_id 有重复，而且因为重复模式不均匀，导致某些 user 的行数被放大得格外夸张。如果当时 merge 时随手加个validate='many_to_one'，这个问题在第一时间就会被捕获，根本不用做那么长时间的“排雷”。

5.3 合并完成后列顺序的管理

merge之后列的顺序也有讲究。默认是 key 列排在最前面，然后左边剩余列，再右边剩余列。这个顺序在大多数场景下没问题，但如果你要输出到 Excel 或者做进一步的可视化，列顺序往往直接影响到表的可读性。

我习惯在 merge 之后显式地重新排列列顺序：

result = pd.merge(left, right, on="key", validate="one_to_one") result = result[["id", "province", "city", "date", "metric_value", "metric_target"]]

这一步看起来只是“整理”，但它强制你重新审视合并后的列结构，能顺便发现一些不该出现的列（比如_x/_y残留），相当于多了一次自查的机会。

6. 高阶实践三：多表合并与性能优化

6.1 链式 merge 与 reduce 模式

在实际的数据管道中，很少只有两张表参与合并。常见的模式是：一张主表，加上多张维表，你想一次性把维表字段都 attach 到主表上。最简单的写法是链式 merge：

df = df_main.merge(df_dim1, on="key1", how="left", validate="many_to_one") df = df.merge(df_dim2, on="key2", how="left", validate="many_to_one") df = df.merge(df_dim3, on="key3", how="left", validate="many_to_one")

这种写法直观，代码可读性也不错，但问题在于它有一些隐藏开销：每次 merge 都会生成一个完整的中间 DataFrame，如果主表行数很大（千万级别），多轮 merge 会占用大量临时内存。

一种更省内存的做法是使用functools.reduce一次性把多个 DataFrame 归并：

from functools import reduce df_merged = reduce( lambda left, right: pd.merge(left, right, on="key", how="left", validate="many_to_one"), [df_main, df_dim1, df_dim2, df_dim3] )

不过说实话，我在生产环境中更倾向于“小步 merge”而不是强行塞进 reduce。原因有两点：一是链式 merge 可以在每步之间插入日志、断言和计数检查，方便定位哪一步出了问题；二是 reduce 虽然看着优雅，但一旦某个维表的 key 有重复，错误信息会和后面几步裹在一起，排查难度显著增大。性能优化很重要，但可维护性同样重要。我的折中方案是：如果维表数量在 2 到 4 张，且主表行数在百万级别，链式 merge 足够；如果维表数量超过 5 张或者主表特别大，那就换用 reduce 或先把维表转成字典用 map 映射。

6.2 用字典映射替代 merge：当只有一列需要映射时

有时候你根本不需要 merge 一整张维表，你只是想把某一列的值根据另一张表的映射关系“翻译”成新的一列。这种场景用map或replace比merge高效得多。

city_map = df_city_info.set_index("city_id")["city_name"].to_dict() df["city_name"] = df["city_id"].map(city_map)

这个操作的复杂度是 O(n) 的字典查找，而merge需要做哈希连接并生成新的 DataFrame，开销要大得多。当主表行数是几百万行、映射表只有几千行时，map方案通常能快一个数量级，内存占用也小得多。

我把这种方法称之为“轻量映射”，因为它只解决“单列补全”的需求。同理，如果你想根据某个 code 映射出一个等级、一个分组名、一个负责人等，都可以先构建一个 dict，再map上去。这比每次都围着 merge 转要灵活得多，代码也更简洁。

6.3 大数据量下的合并策略：分块、类型压缩与内存预估

当你需要合并的表非常大，比如单个 DataFrame 已经超过内存的 30%，就要开始考虑性能策略了。这里我必须强调：Pandas 的 merge 在数据量大时的主要瓶颈不是 CPU，而是内存。合并过程中会构建哈希表，加上中间结果和复制操作，内存峰值可能达到原始数据的好几倍。

我常用的优化手段有四个：

第一，合并前先筛选列。只保留参与合并的 key 列和最终有用的业务列，把那些无关的大文本列、冗余列先 drop 掉，减少内存里的数据量。

第二，数据类型压缩。把object类型的列转成category，把int64降成int32甚至int16，把float64降成float32。这一套操作对内存的节省非常可观，尤其是在列数多、行数大的场景下。

for col in df.columns: if df[col].dtype == "object": df[col] = df[col].astype("category")

第三，分块 merge。如果主表实在太大，可以按 key 的某个维度拆块，每一块分别 merge 之后 concat 到一起。这个办法虽然代码稍微复杂，但能把内存峰值控制在一个可控范围内。

第四，如果可以，优先用merge的left连接并且把右表去重。右表的 key 如果唯一，哈希表会更小，merge 也更快。如果右表有充足的内存空间，可以先drop_duplicates。

另一个容易被忽视的点：合并前对 key 列做排序不一定能加速 merge，但如果你在 merge 之后还需要按 key 排序，反而可以先 sort 再 merge，让结果直接有序。这样省掉一次全局排序，对后续输出很友好。

7. 合并后的数据质量检查与常见问题速查

7.1 合并结果的三个黄金检查点

无论用concat还是merge，合并完成之后我都会执行三个检查步骤，几乎成了肌肉记忆：

第一，行数是否符合预期。如果是 left 连接，结果行数等于 left 的行数；如果是 inner 连接，行数应该小于等于两个表去重匹配后的行数。任何超出预期的行数变化，都是危险的信号。

assert len(result) == len(left), f"行数异常: {len(result)} vs {len(left)}"

第二，key 是否真的能对上。检查 join 前后是否有 NaN 或异常重复。

missing = result[result["right_key"].isna()]

如果是左连接，missing 里的行就是 left 中没匹配上的部分，要判断这些行是否符合业务预期。

第三，字段是否完整。检查合并后有没有出现不应该出现的_x/_y列，检查最终列数是否和预期一致。这一步能快速捕获 columns 冲突和 suffixes 设置不当的问题。

7.2 常见问题速查表

我整理了下面这个速查表，很多问题你会觉得眼熟，因为它们大多来自我自己的错误案例。

第三行里那种“两边 key 看起来一样但匹配不上”的情况，最容易让人崩溃。我遇到过一例，两边都是字符串形式的 ID，但因为一边是从 Excel 读的，带了不可见字符，另一边是从数据库导出的干净字符串，怎么 merge 都是 NaN。检查了很久才发现数据里藏着换行符。对策是先在 key 列上执行astype(str).str.strip()，再统一数据类型，基本能排除绝大多数“假不匹配”问题。

7.3 合并性能与内存的典型瓶颈定位

如果你发现合并特别慢，不要急着怀疑 Pandas 的性能，先做两件事：一是确认数据量，二是确认列数。很多时候慢的根本原因是右表太大，导致哈希索引构建耗时，而你可能根本用不到右表的全部列。另一个常见瓶颈是数据类型不统一——object类型会比category或定长数值类型慢得多，因为比较的开销完全不同。

内存瓶颈的判断稍微麻烦一点。一个简单的方法是在 merge 前后用df.memory_usage(deep=True)对比峰值。如果你发现合并后的内存远大于两组数据之和，那大概率是发生了笛卡尔积式的行扩张，或者列冲突导致结果表包含了大量冗余列。这两种情况都值得停下来好好审视合并策略。

如果数据量到了“无论如何优化内存都不够”的程度，我会果断换用polars或者干脆把数据导入数据库里做 JOIN，不再硬磕 Pandas。工具选型不重要，能解决业务问题才是第一位的。

8. 一个完整的实战案例：多表关联的数据清洗流程

8.1 场景描述

假设我们有一个电商订单明细表orders，包含列：order_id、user_id、product_id、order_amount、order_date。另有一张用户维表users，包含列：user_id、user_region、register_date。还有一张商品维表products，包含列：product_id、product_name、category、price。

需求是生成一张“订单分析宽表”，包含每个订单的用户地域、商品名称和类别，最终输出一份按地域、类别汇总的销售额报表。

8.2 第一步：清洗与类型统一

先对orders做基础清洗，确保user_id和product_id都是字符串类型，且没有多余空格：

orders["user_id"] = orders["user_id"].astype(str).str.strip() orders["product_id"] = orders["product_id"].astype(str).str.strip() users["user_id"] = users["user_id"].astype(str).str.strip() products["product_id"] = products["product_id"].astype(str).str.strip()

这个步骤看起来琐碎，却是我处理一切外部数据的第一步，也是 merge 能正常工作的基础。

8.3 第二步：维表预检与合并

在真正 merge 之前，先检查维表的 key 是否有重复：

assert users["user_id"].is_unique, "用户维表 user_id 存在重复" assert products["product_id"].is_unique, "商品维表 product_id 存在重复"

通过断言后，再执行两次左连接：

df_wide = orders.merge(users, on="user_id", how="left", validate="many_to_one") df_wide = df_wide.merge(products, on="product_id", how="left", validate="many_to_one")

这里validate="many_to_one"的意思是：左表（订单）的 user_id 可以重复，但右边的维表 key 必须唯一。如果维表里有重复 key，这条语句会直接抛异常，等于在源头拦住脏数据。

8.4 第三步：合并后检查与汇总

合并完成后，检查是否有未匹配上的订单：

unmatched_user = df_wide[df_wide["user_region"].isna()] unmatched_product = df_wide[df_wide["product_name"].isna()]

如果这两部分不为空，说明订单里存在用户维表或商品维表没有覆盖的记录。根据业务规则，这类记录要么保留并标记为“未知”，要么直接剔除。保留时我习惯做一层填充：

df_wide["user_region"] = df_wide["user_region"].fillna("未知") df_wide["product_name"] = df_wide["product_name"].fillna("未知商品")

最后按地域和类别做汇总：

summary = df_wide.groupby(["user_region", "category"], as_index=False)["order_amount"].sum()

这个案例完整走下来，你就能看到合并 API 在真实业务链路中的定位：它不只是把两张表拼在一起，而是围绕数据质量保证、键一致性检查、缺失值处理的一整套流程。如果第一步和第二步做得够稳，第三步基本就是水到渠成。

8.5 为什么这个流程值得复制

很多人写数据管道，习惯把 merge 当作一个“瞬间动作”，合并完就立刻去做统计，中间完全不做检查和校验。这种做法的风险在数据量小的时候不明显，一旦数据量大到无法人为抽查，任何底层数据的质量问题都会在统计结果层面被放大。我上面这套流程的本质，是把 merge 前面加上“类型统一、重复检查”，merge 后面加上“匹配率检查、缺失值标记”，让每一步都有迹可循。这套方法论比任何一个单独的 API 技巧都重要。

9. 一些个人的经验与最终提醒

在我自己的项目中，合并 API 的选择已经成了一种近乎本能的决策过程。数据来了，先看结构是否同质，同质就concat；再看是否有业务键需要关联，有关联就用merge；如果只是索引对齐，就join；如果只是补一列映射，就map。这个决策链非常简单，但它能帮我把 90% 的合并需求在三秒内归位，剩下的 10% 才是真正需要设计的地方。

如果说有什么想特别强调的，那就是不要迷信单一的 API。merge不是万能的，concat也不是只有“上下拼”这一个用途。Pandas 的合并 API 之所以看起来冗杂，是因为数据合并本身就是一门关于对齐、匹配和容错的学问。你用得越深，越会发现所谓的“API 选型”其实是在一个大的语义框架下做决策。

最后分享一个小技巧：当你对某个合并行为不确定时，建一个只有三五行的小例子，跑一遍，看看索引、行数、列名、NaN 分布是否符合预期。这个习惯能帮你避免无数个小时的排错时间。Pandas 的返回值是透明的，小例子会把它的行为方式完完整整地展示给你——剩下的，就是你把这种“确定感”搬到真实的大数据上。