combine_first只填充NaN而不覆盖非空值，因其设计逻辑是“以左为基准补全”，仅用右侧数据填补左侧NaN空缺，对0、空字符串等非NaN值视作有效数据不予替换。
combine_first 为什么只填充 NaN 不覆盖非空值
combine_first 的设计逻辑就是“用右侧数据补左侧的空缺”，它不会主动覆盖左侧已有的有效值。这和 fillna 或 update 有本质区别：前者是“以左为基准补全”，后者才可能修改已有值。
常见错误现象：df1.combine_first(df2) 后发现 df2 里明明有更“新”的值，但没生效——大概率是因为 df1 对应位置不是 NaN，而是 0、空字符串 '' 或 False。这些都不是 combine_first 认可的“空值”。
- 使用前先确认空值类型：
df1.isna().sum()看哪些列真有NaN - 若需把
0或''当空处理，得先手动转成NaN：df1.replace({0: pd.NA, '': pd.NA}).combine_first(...) - 注意
combine_first按列名对齐，列名不一致会直接新增列，不是覆盖
重叠列合并时索引对齐出问题怎么办
当两个 DataFrame 的索引不一致（比如一个是 range(3)，另一个是 [0, 2, 4]），combine_first 会按索引做 outer join 式对齐，结果行数可能变多，且顺序可能打乱。
典型场景：你有一份日报数据 df_daily 和一份修正数据 df_corrected，但后者只更新了其中某几天，索引是日期，但缺失部分日期。
- 确保索引类型一致：
df1.index = pd.to_datetime(df1.index)，否则字符串'2023-01-01'和 datetime 无法对齐 - 如果只想合并“相同索引行”，别依赖默认行为，先用
df2.reindex(df1.index)对齐再combine_first - 性能影响：大表做
combine_first时，索引越复杂（如 MultiIndex），对齐开销越大；简单整数索引最快
combine_first 与 update / fillna 的关键区别在哪
三者都涉及“用一个 DataFrame 补另一个”，但语义完全不同：
-
combine_first：返回新 DataFrame，左主右补，保留左的所有列 + 右的额外列，只填NaN -
update：原地修改左 DataFrame，只更新左中已存在的列，右中新增列被忽略，且默认不覆盖NaN（除非设overwrite=True） -
fillna：只作用于单个 DataFrame，不能跨表，且只能填标量或同维 Series
容易踩的坑：df1.update(df2) 后发现没变化？检查 df2 列名是否完全匹配 df1，多一个空格或大小写不同就失效；而 combine_first 遇到列名不匹配会直接加新列，反而“看起来有变化”。
合并后出现 dtype 不一致或隐式转换
比如 df1.col 是 int64，含 NaN；df2.col 是 float64，combine_first 结果列会变成 float64——因为 pandas 要兼容 NaN，int 列一旦有空就自动升为 float。
这不是 bug，是 pandas 类型系统的限制。如果你后续要导出到数据库或做 int 运算，这个细节很关键。
- 若想保留整数类型（用
pd.Int64Dtype()），得在合并前统一：df1.col = df1.col.astype('Int64') - 合并后检查 dtype：
result.dtypes，尤其关注数值列是否意外变成 object（常因混入字符串导致） - 避免先
combine_first再astype(int)—— 会报错，NaN 不能转 int
重叠列合并真正的麻烦不在语法，而在你是否清楚每列当前的空值定义、索引结构和 dtype 约束。漏掉任意一点，结果都可能和预期差一层意思。
