numpy数组比python列表快数十倍，因其采用连续内存布局、调用c底层向量化运算；而列表是分散的指针数组，易缓存未命中且需频繁类型检查与对象操作。
内存布局不连续，Python列表天生不适合数值计算
Python列表本质是对象指针数组，每个元素指向堆上独立分配的int、float等对象。这些对象地址随机分布，CPU缓存预取失效，每次访问都要解引用+查类型+找__add__方法。而np.ndarray是一整块连续C内存，比如np.zeros(1000000, dtype=np.float32)直接分配4MB对齐内存，CPU可批量加载、SIMD并行处理。
常见错误现象：np.array([1, 2.0, "x"])会退化为dtype=object，所有运算回退到Python解释器层，速度反不如原生列表。
- 初始化时务必显式指定
dtype，如np.float32比默认float64省一半内存带宽 - 避免混合类型：含字符串、
None或自定义对象的列表转np.array必踩坑 -
sys.getsizeof()显示列表本身小，但sum(sys.getsizeof(x) for x in lst)才反映真实开销
向量化不是语法糖，是绕过解释器的C函数调用
写a + b时，NumPy不走Python循环，而是调用底层PyArray_GenericBinaryFunction，传入两个内存块起始地址、长度、strides和dtype，整个加法在C层用指针偏移完成，零Python对象创建、零动态类型检查。
对比[x**2 for x in range(1000000)]：每个x**2要经历对象查找→类型分发→运算符重载→结果封装四步；而np.arange(1000000) ** 2直接映射到powf或pow，编译器自动展开为AVX2指令（一次8个float64）。
-
np.add(a, b, out=result)复用已有数组内存，避免临时分配开销 -
np.where带复杂条件（如嵌套and/or）时部分路径仍fallback到解释器，优先用布尔索引 -
np.vectorize只是包装器，底层仍是Python循环，不解决性能问题
广播机制靠strides调度，不是复制数据
广播不是“把小数组复制成大形状”，而是通过调整strides让不同形状的数组共享同一块内存。例如(3, 4) + (4,)中，后者被解释为第0维步长为0（重复3次），实际没生成新数据。
容易踩的坑：ValueError: operands could not be broadcast together根本原因不是维度数不同，而是某维长度既不相等、也不为1——比如(3, 4) + (5,)就失败，因为4≠5且都不为1。
-
arr[:, None] + arr[None, :]生成(n, n)矩阵看似暴力，但全程无Python循环，纯C层strides调度 - 广播后输出尺寸爆炸（如
(10000, 1) + (1, 10000)→(10000, 10000)），必须提前算好内存是否够用 - 用
np.broadcast_arrays可预检广播兼容性，避免运行时报错
小数组反而可能更慢，别盲目替换
数组太小时，NumPy初始化开销（内存分配、dtype推断、C函数调用跳转）可能超过Python循环本身。实测len 时，原生列表有时更快。
性能拐点取决于硬件缓存线大小、CPU分支预测效率和具体运算类型。幂运算、三角函数等重计算操作，NumPy优势从几十个元素就开始显现；但简单加减，往往要上千元素才拉开差距。
- 高频小数组场景（如粒子模拟每帧更新几十个坐标），先用
timeit实测，别凭经验替换 - 混合使用时警惕隐式转换：
list(arr) + [1, 2]触发全量拷贝，后续计算无法向量化 - 真要极致性能，小数组可用
numba.jit编译Python循环，比NumPy还快
关键点在于：快不是因为“用了C”，而是连续内存+固定类型+向量化指令这条通路避开了Python解释器的所有运行时开销。一旦打破任一前提（比如dtype混杂、内存不连续、强制转list），加速就立刻消失。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
