向量化操作快是因为绕过Python解释器，交由C/Fortran或SIMD批量处理；for循环每轮需类型检查、对象查找、引用计数等开销，百万次迭代放大至不可忽视程度。
因为向量化操作根本没走 Python 解释器那套流程——它把整个数组交给 C 层函数一次性算完，而 for 循环每轮都要查类型、找对象、更新引用计数、调度字节码，这些开销在百万次迭代里被放大到无法忽视的程度。
底层执行路径完全不同
写 for x in arr: s += x，Python 解释器要为每个 x 做：取值 → 判断类型 → 查 __add__ 方法 → 构造新 float 对象 → 更新 s 引用 → 触发 GC 检查。100 万次就是 100 万次完整对象生命周期管理。
换成 np.sum(arr) 或直接 arr.sum()，只触发一次 C 函数调用，内存上连续扫描、SIMD 并行加法、缓存预取全开，中间不经过任何 Python 对象系统。
- 实测：对 1000 万元素
float64数组求和，for循环约 1.8 秒；np.sum()约 0.007 秒（250 倍差距） - 瓶颈从来不在“加法本身”，而在“每次加法前后的解释器包袱”
-
np.add(a, b)不是“更快的加法”，而是“跳过解释器的加法”
广播机制省掉显式循环和内存复制
比如二维数组每行减去该行均值：data - data.mean(axis=1, keepdims=True)。这里 data.mean(...) 返回的是 (N, 1) 形状，NumPy 不会把它扩成 (N, D) 再做减法，而是用步长（stride）控制指针偏移，在内存上“逻辑展开”，零拷贝。
- 手写双层
for i in range(N): for j in range(D): data[i,j] -= row_mean[i]—— 缓存不友好、无 SIMD、纯 Python 调度 - 错用
np.tile(row_mean, (1, D))再减 —— 内存暴涨，可能 OOM - 正确姿势永远优先靠 broadcasting，而不是靠
np.expand_dims+np.tile
常见误用反而更慢
向量化不是语法糖，也不是“写得短就快”。很多看似向量的操作，实际性能比手写循环还差。
-
np.vectorize(func)：只是 for 循环包装器，且带额外对象开销，通常比原生for还慢 2–3 倍 -
df['col'].apply(lambda x: x**2)：本质是 Python 循环 + Series 构造，不如df['col'].values ** 2 -
np.append(arr, x)在循环里反复调用：每次 realloc 内存，复杂度 O(n²)，10 万次追加可能卡死 - 数组小于 1000 元素时，
for和np.where差距微乎其微，甚至for更快（函数调用+临时数组分配成本反超）
真正决定是否加速的，从来不是“用了 NumPy”，而是“数据是否已在内存、结构是否连续、逻辑是否无状态依赖”。I/O 没读完、数据还在 list 里、计算要等上一个结果——这时候谈向量化，就像给拖拉机装涡轮增压。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
