str.cat比+更安全，因其专为字符串设计：自动跳过NaN、支持na_rep占位，且能隐式处理category类型；而+遇NaN返回NaN、不兼容数字或category列，易报错。
str.cat 为什么比直接加更安全
直接用 + 合并两列字符串（如 df['a'] + df['b']）在遇到 NaN 时会返回 NaN，整行数据就丢了；而 str.cat 默认跳过 NaN，还能用 na_rep 指定占位符。这不是“更高级”，是它专为字符串拼接设计的容错机制。
-
str.cat是Series.str的方法，只作用于字符串型 Series，对非字符串类型会报AttributeError: Can only use .str accessor with string values - 必须显式传入另一个 Series 或 list，不能写成
df['a'].str.cat(df['b'])这种看似自然但实际报错的写法——正确是df['a'].str.cat([df['b']], sep='') - 如果想用
sep=' '加空格，注意两端空格是否需要：它不会自动 strip，'a '和' b'拼出来就是'a b'
直接相加（+）的适用场景和坑
纯 ASCII 字符串、确定无缺失值、且不需要自定义分隔逻辑时，+ 最快也最直觉。但它本质是 Python 的 __add__，不关心语义，也不做类型检查。
- 只要其中一列是
object类型但含数字（如123），就会触发TypeError: can only concatenate str (not "int") to str - 如果某列是
category类型，+会失败，而str.cat可以先隐式转为 string（前提是 category 值本身可转） - 合并后结果的 dtype 是
object，即使原两列都是string（pandas 1.0+ 的 nullable string dtype），这点容易被忽略
处理缺失值时的三选一策略
合并含 NaN 的列，核心不是选函数，而是明确业务意图：丢弃？补空字符串？补特定标记？
- 想丢掉整行：用
df['a'].fillna('').str.cat(df['b'].fillna(''), sep='')—— 先填再拼，最可控 - 想保留
NaN位置：用df['a'].str.cat([df['b']], na_rep='', sep='')，na_rep只影响参与拼接的列中的NaN，不改变索引对齐 - 想让结果中
NaN只出现在“全空”时：得手动判断，比如df[['a','b']].apply(lambda r: (r['a'] or '') + (r['b'] or ''), axis=1)，但性能差，仅小数据可用
性能差异真有那么大吗
在万行以内，+ 和 str.cat 耗时差别不到 10%，不用过早优化；但超过十万行，str.cat 在底层用了更紧凑的字符串缓冲区，实测快 1.5–2 倍，尤其当 sep 非空时优势更明显。
- 避免嵌套调用：不要写
df['a'].str.cat([df['b'].str.upper()])，先算好df['b'].str.upper()再传进去，否则每行都重复执行 upper - 如果只是简单连接且无
NaN，+的字节码更少，PyPy 下可能更快，但 CPython 是主流 - 真正拖慢的是混合类型或链式操作，比如
df['a'].str.strip().str.cat(...)，中间生成了多个临时 Series
实际拼接前，先用 df[['col1', 'col2']].dtypes 和 df[['col1', 'col2']].isna().sum() 看一眼数据底细，比硬套语法更重要。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
