NumPy ufunc 比 Python for 循环快，因其底层为 C 实现，支持自动广播、连续内存访问和 SIMD 优化；而 for 循环需频繁解释执行、类型检查和对象查找。
为什么用 np.add、np.sin 这类 ufunc 比 for 循环快？
因为 NumPy 的 ufunc（universal function）底层是 C 实现的，自动广播、内存连续访问、SIMD 指令优化全都有；而 Python 的 for 循环每次都要做类型检查、对象查找、解释执行，慢一个数量级起步。不是“看起来简洁”，是真正在 CPU 层面绕过了 Python 解释器瓶颈。
哪些操作能直接换成 ufunc，哪些不能？
能换的：所有逐元素纯函数计算，比如加减乘除、三角函数、指数对数、比较运算（np.greater）、逻辑运算（np.logical_and）。不能换的：依赖前序结果的迭代逻辑（如累加、滑动窗口）、条件分支嵌套过深、需要访问索引位置本身（如 i % 3 == 0）。
-
arr * 2 + np.sin(arr)✅ 直接写，不用for -
np.where(arr > 0, np.sqrt(arr), 0)✅ 用np.where向量化条件赋值 -
result[i] = result[i-1] + arr[i]❌ 必须用np.cumsum或其他专用函数，不能硬套 ufunc
自定义函数也能向量化？np.vectorize 是个坑
np.vectorize 只是语法糖，它不加速——本质还是 Python 循环调用你的函数，只是帮你处理了广播。真正提速得靠 numba.jit 或写 C 扩展。如果非要用 Python 写逻辑，优先考虑：np.select、np.piecewise、布尔索引组合。
- 错例：
vfunc = np.vectorize(lambda x: x**2 if x > 0 else 0)→ 比原生for还慢 - 对例：
result = np.zeros_like(arr); mask = arr > 0; result[mask] = arr[mask] ** 2 - 更优：
np.where(arr > 0, arr ** 2, 0)
广播机制没配对好，会静默出错或结果错位
ufunc 自动广播，但维度不兼容时不会报错，而是按规则扩展——容易导致结果 shape 不对、数值错乱。调试时先用 arr.shape 和 arr.ndim 看清输入维度，再手动验算广播后 shape。
立即学习“Python免费学习笔记（深入）”；
-
a = np.ones((3, 4)); b = np.ones((4,))→a + b合法（b 扩展为 (1,4) 再广播） -
a = np.ones((3, 4)); b = np.ones((5,))→ValueError: operands could not be broadcast together - 常见陷阱：
arr_2d[:, None] + arr_1d是列方向广播，不是行方向——别凭感觉写
ufunc 加速不是“用了就快”，关键在是否真把计算压到了底层连续内存操作上；广播写错、混用 np.vectorize、忽略 dtype 隐式转换（比如 int64 + float32 → float64），都可能让向量化变成负优化。
