NumPy数组比Python列表快的核心原因是内存连续且类型固定。列表存储对象指针，需频繁查类型和跳地址；ndarray是连续C内存块，存原始数值，支持SIMD批量处理与零开销类型检查。
NumPy 数组为什么比 Python 列表快？
核心就一条：内存连续 + 类型固定。Python 列表是对象指针数组，每个元素都要查类型、查引用、跳内存地址；numpy.ndarray 是一块连续的 C 风格内存块，存的是原始数值（比如 64 位浮点数），CPU 可以用 SIMD 指令批量处理，也不用为每个数做类型检查。
实操建议：
- 别用
np.array([1, 2, "3"])这种混合类型——会退化成object类型数组，失去所有加速优势 - 初始化时显式指定
dtype，比如np.zeros(1000, dtype=np.float32)，避免默认float64浪费内存和带宽 - 避免频繁用
.tolist()或list(arr)转回 Python 列表，这会触发全量拷贝，且后续计算无法向量化
广播机制（broadcasting）是怎么省掉循环的？
广播不是语法糖，是 NumPy 在底层用 C 实现的内存步长（strides）调度。它让不同形状的数组在不复制数据的前提下，按规则“对齐”访问同一块内存。比如 (3, 4) + (4,)，后者会被解释为在第 0 维“重复 3 次”，但实际没生成新数组，只是调整了它的 strides 和 shape。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
-
ValueError: operands could not be broadcast together—— 不是维度不等，而是某维长度既不相等、也不为 1 - 误以为
arr[:, None] + arr[None, :]会慢：其实它比双层for快几十倍，因为仍是纯 C 层广播，没 Python 循环介入 - 广播后结果变大（如 (1000, 1) + (1, 1000) → (1000, 1000)），容易爆内存，得提前算好输出尺寸
np.vectorize 并不真正加速
np.vectorize 是个伪装成向量化的函数包装器，底层仍是 Python 循环调用你的函数。它只解决“写法统一”，不解决性能问题。真要提速，得用原生 NumPy 函数、Numba 编译，或手动改写为广播表达式。
使用场景：
- 调试时快速验证逻辑，比如
np.vectorize(lambda x: x**2 if x > 0 else 0)(arr) - 封装已有的标量函数，供接口兼容，但生产环境必须替换
- 别把它和
np.where、np.clip、布尔索引混用——那些才是真向量化操作
内存布局（C vs Fortran order）影响性能
NumPy 默认用 C-order（行优先），即 arr[i, j] 的内存地址变化主要在 j 上。如果你大量按列操作（比如 arr[:, k]），而数组是 C-order，就会导致 CPU cache miss 频繁——因为每取一个元素，要跳过整行长度。
实操建议：
- 用
arr.T.copy()或np.asfortranarray(arr)显式转为 F-order，再按列切片，速度可能翻倍 - 创建大数组时，如果确定主要按列访问，直接用
order="F"：np.zeros((10000, 100), order="F") - 用
arr.flags查看C_CONTIGUOUS/F_CONTIGUOUS，别凭直觉猜内存是否连续
复杂点在于：广播、切片、转置都会改变 strides，但不一定改变 flags.contiguous。很多加速技巧失效，不是代码写错，而是你手里的数组早已不是连续内存块了。
