向量化操作本质是绕过Python解释器，交由C/Fortran或SIMD批量处理，故天然高效；df['a']+df['b']因调用NumPy预编译C函数而比Python循环快10–100倍；np.where纯向量化，df.apply则本质是带对象开销的Python循环；强依赖、不可向量化函数、内存敏感时需谨慎；链式赋值易产生视图导致失效，须用.loc确保正确性。
向量化操作不是“更快的循环”，而是完全绕开了 Python 解释器层的逐元素调度——它把整列/整数组交给底层 C/Fortran 或 SIMD 指令批量处理，所以快是必然的，慢才是误用导致的。
为什么 df['a'] + df['b'] 比 for i in range(len(df)): 快 10–100 倍
根本原因不在语法糖，而在执行路径：
-
df['a'] + df['b']触发 Pandas 内置的__add__，最终调用 NumPy 的np.add()，走的是预编译的 C 循环 + 缓存友好内存访问 -
for i in range(len(df)):每次都要：Python 解释器查索引、取值、类型检查、对象引用计数、再赋值——全是解释器开销 - 实测 500 万行两列相加：
df['a'] + df['b']耗时约 0.012 秒；iterrows()循环做同样事耗时约 109 秒（数据来自 2025 年 7 月基准测试）
np.where() 和 df.apply() 的性能与语义差异
两者都常被当作“条件计算”的入口，但行为和代价天差地别：
-
np.where(condition, x, y)是纯向量化三元运算：condition、x、y 都需可广播，全程无 Python 函数调用栈 -
df.apply(lambda x: ...)（尤其axis=1）本质是 Python 层 for 循环 + 每次构造 Series 对象，哪怕函数本身很轻量，开销也集中在对象创建和属性访问上 - 字符串操作同理：
df['name'].str.upper()走的是 Pandas 内置向量化字符串方法；df['name'].apply(str.upper)则对每个元素调用一次 Python 函数，且不跳过 NaN（需额外na_action='ignore'）
什么情况下不能/不该向量化
强行向量化会牺牲可读性或引入错误，这时候得接受循环，但要选最小代价方案：
立即学习“Python免费学习笔记（深入）”；
- 存在强数据依赖：比如当前行结果依赖前一行累计值（如移动平均、状态机），
np.cumsum()或pd.Series.expanding()可覆盖部分场景，但通用逻辑仍需for - 调用无法向量化的第三方函数：例如某个闭源 SDK 只提供单样本接口，此时优先用
itertuples(index=False, name=None)替代iterrows()，字段访问用下标row[0]而非属性名，提速 2–3 倍 - 内存敏感场景：向量化常需临时分配大数组（如广播后 shape 翻倍），
df.groupby().apply()分块处理有时比全量np.where()更稳
真正容易被忽略的不是“要不要向量化”，而是“向量化之后有没有隐式拷贝”——比如链式赋值 df[df['x'] > 0]['y'] = 1 不生效，因为中间产生视图；必须用 .loc 或先筛选再赋值。性能优化永远和正确性绑定，漏掉这点，快也是白快。
