核心原因是apply默认逐组构造新DataFrame/Series对象，触发完整Python层循环和对象开销，而agg/transform在底层尽可能复用向量化操作或C优化路径。
核心原因是 apply 默认逐组构造新 DataFrame/Series 对象，触发完整 Python 层循环和对象开销，而 agg/transform 在底层尽可能复用向量化操作或 C 优化路径。
apply 默认走 Python 解释器循环，无法跳过对象构建
当你对 groupby 对象调用 apply(func) 且未指定 axis 或传入标量函数时，pandas 会为每一组单独提取子 DataFrame（或 Series），再把该子对象传给你的函数。这个过程包含：
- 每组都新建一个 pandas 对象（含索引、dtype 检查、内存拷贝等）
- 函数调用在 Python 解释器中执行，无法被 numba/Numpy 的 C 循环加速
- 返回值还要被收集、拼接、对齐，涉及额外的索引重建和类型推断
agg 和 transform 优先调用内置优化实现
像 .agg(['mean', 'sum']) 或 .transform('std') 这类操作，pandas 会直接映射到内部已编译的高效路径：
- 绕过 Python 层，直接调用 NumPy 的 ufunc 或 Cython 实现的分组聚合（如
libgroupby模块） - 不构造中间组对象，而是通过指针偏移 + 长度信息，在原始数组上做原地计算
- 支持输出广播（transform）或压缩（agg）的零拷贝优化，避免冗余内存分配
即使写自定义函数，apply 也难逃开销瓶颈
比如你写 df.groupby('key').apply(lambda x: x['val'].mean())，看似简单，但实际仍经历：
- 每组生成
x（DataFrame 子视图或副本，取决于是否可切片） - 再从
x中取列'val'→ 又一次对象访问和 Series 构造 - 调用
.mean()—— 虽然这个方法本身是优化的，但外层 apply 的调度成本已远超计算本身
换成 df.groupby('key')['val'].agg('mean')，就直接走分组+数值列均值的专用通道，跳过所有中间对象。
怎么缓解 apply 的性能问题
如果必须用 apply，可通过以下方式减少损耗：
- 用
groupby(...).apply(func, include_groups=False)（pandas ≥ 2.1）避免传入 group key 列 - 确保函数接收的是 Series（如先选列：
df.groupby('key')['val'].apply(...)），比传整个 DataFrame 快数倍 - 用
numba.jit加速纯数值计算逻辑，并配合Series.to_numpy()输入，彻底脱离 pandas 对象 - 能用
agg/transform+ 字符串名 / 内置函数 / 元组组合的，绝不手写 apply
