NumPy 的 np.dot 更快是因为绕过 Python 解释器的类型检查、内存寻址和对象引用开销，直接在连续内存上执行 BLAS 级别点积，而非逐元素解释执行。
为什么 NumPy 的 np.dot 比 Python 循环快几十倍
根本原因不是“底层用 C 写的”这么笼统——而是它绕过了 Python 解释器对每个元素的类型检查、内存寻址和对象引用开销。循环里每次 a[i] * b[i] 都要查 a 是不是 list、i 是不是 int、乘完结果要不要新分配 float 对象；而 np.dot 一次性告诉 CPU：“按这块连续内存里的 float64，做 BLAS 级别的向量点积”，中间不经过 Python 字节码。
实操建议：
- 别用
for i in range(len(arr)):做逐元素计算，哪怕只是加个标量——改用arr + 5 - 遇到嵌套循环（比如手动实现矩阵乘），先查 NumPy 是否有对应函数：
np.matmul、np.einsum、@运算符 - 如果必须写循环，且数组很大，考虑用 Numba 的
@njit编译，但注意它不支持任意 Python 对象（如 dict、str）
np.vectorize 并不加速，只是语法糖
很多人误以为加了 np.vectorize 就自动向量化——其实它只是把你的 Python 函数包装成“看起来能广播”的接口，底层仍是 for 循环调用原函数，甚至比手写循环还慢，因为多了额外的参数分发和 dtype 推断开销。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 用
np.vectorize(my_custom_func)处理百万级数组，耗时反而比纯 Python 列表推导式更长 - 函数里用了
print或logging，结果发现每元素都打印一次——证明它真在挨个调用
真正该做的：
- 把逻辑拆成 NumPy 原生操作：比如想对每个数取 log 后平方，写
np.log(x) ** 2，而不是封装lambda x: np.log(x)**2再 vectorize - 实在无法避免自定义逻辑（比如分段函数），优先用
np.where或布尔索引：result = np.where(x > 0, np.sqrt(x), x * 2)
广播（broadcasting）不是免费的，但比显式循环便宜得多
广播本身不复制内存，但它需要实时计算每个轴的步长（stride）和元素偏移。小数组几乎无感，但高维张量（比如 (1, 512, 512) 和 (3, 1, 1) 相加）会触发多层嵌套索引计算——这时如果能提前 reshape 成兼容形状，性能可能提升 10%~20%。
使用场景与建议：
- 做图像批处理时，别让模型输入是
(batch, h, w, 3)而均值是(3,)——显式 reshape 成(1, 1, 1, 3)，避免运行时反复推导广播规则 - 用
np.broadcast_arrays预检两个数组是否可广播，避免在循环里反复触发ValueError: operands could not be broadcast together - 广播遇上
np.nan要小心：np.array([1, np.nan]) + 0得到[1., nan]，但若广播后某路径没触发计算，NaN 可能意外消失（尤其配合np.any/np.all）
GPU 加速不是“换库就行”，得看数据搬运成本
用 CuPy 或 PyTorch 把数组搬到 GPU 上跑 cp.dot，只在计算远大于 PCIe 带宽延迟时才划算。比如单次矩阵乘 (2048×2048)，GPU 显著快；但对 (100×100) 数组做 1000 次小 dot，频繁 Host↔Device 搬运反而拖垮整体。
关键判断点：
- 用
time.perf_counter()分别测纯 CPU 计算、数据上传、GPU 计算、数据下载四段耗时——如果上传+下载 > 计算本身，就别上 GPU - CuPy 的
cp.asarray不拷贝内存，但首次调用时会隐式同步，容易误判为“启动慢”；建议预热：cp.ones((10,10)); cp.cuda.Stream.null.synchronize() - 混合精度（
cp.float16）在 GPU 上快，但在 CPU 上可能因强制转 float32 反而更慢，别盲目降精度
实际项目里最常被忽略的，是向量化前的数据组织方式——比如把列存 CSV 用 pandas.read_csv 默认读成 object 类型的列，后续所有 .values 转 NumPy 都带类型转换开销；直接指定 dtype 或用 polars 读，才能让向量化真正落地。
