apply本质是Python层for循环，非向量化操作，绕过NumPy C优化；axis=1时每行构造Series、类型推断、索引对齐，开销远超计算；字符串处理必须用.str接口，避免lambda回调；swifter仅试探路由，限制多且易出错；真正提速应优先使用向量化方法。
因为 apply 本质是 Python 层 for 循环，不是向量化操作 —— 它绕过了 NumPy 的 C 层优化，每次调用都触发对象构造、类型推断和索引对齐，开销远超计算本身。
为什么 df.apply(..., axis=1) 特别慢？
传 axis=1 时，pandas 为每一行单独构造一个 Series 对象（含完整索引、dtype、name），再塞进你的函数；返回值还要重新 infer 类型、对齐索引。十万行 = 十万次 Series 构造 + 十万次 Python 函数调用。
-
df['A'] + df['B']比等价的df.apply(lambda x: x['A'] + x['B'], axis=1)快 50–200 倍 - 哪怕加
raw=True，也只是跳过Series构造、改传numpy.ndarray，仍是逐行调度，提速仅约 3–5× - 函数里带
if/else、字符串切片、正则或外部 API 调用，性能会断崖式下跌
字符串处理千万别用 apply，必须走 .str 接口
像 df['col'].apply(lambda x: x.replace('a', 'b')) 是纯 Python 循环 + GIL 锁死 + 频繁字符串对象创建，完全没走 pandas 底层 C 实现。
- 字面量替换：用
df['col'].str.replace('old', 'new', regex=False)，走 Cmemcmp路径 - 正则替换：先
pattern = re.compile(r'...')，再传给str.replace(pattern, 'new') - 别在
str.replace()里传lambda或 callable —— 那又掉回 Python 回调 - 含
NaN列记得显式设na=True或na=False，避免内部多一层分支判断
swifter 不是加速器，是试探性路由，还一堆限制
它只包了一层“采样→预热→决定是否切后端”的逻辑，不会改你的函数。很多场景下首次执行反而更慢，且容易踩坑：
立即学习“Python免费学习笔记（深入）”；
- 字符串列含
NaN时，默认allow_dask_on_strings=True会触发TypeError: expected bytes, got float - 不支持
groupby().apply()、rolling().apply()，配了也白配 - 不支持
result_type参数，要统一返回类型得在函数里手动转，比如float(x) if pd.notna(x) else np.nan - 真需要并行时，
concurrent.futures.ProcessPoolExecutor更可控 —— 但别传整个DataFrame，用np.array_split(df.values, n_chunks)切数组传过去
真正卡住的时候，往往不是函数写得差，而是没意识到 apply 从设计上就拒绝快 —— 它负责兜底，不负责性能。最该花时间的地方，其实是看一眼官方文档里那个操作有没有 .str.、.dt. 或直接支持数组运算。
