NumPy 运算更快的关键在于绕过 Python 解释器开销、使用连续内存与向量化指令，而非单纯“用了 C”；小数组易受缓存未命中和初始化开销影响，需保持数据连续、类型单一、操作可并行。
NumPy 运算比 Python 原生 list 快，不是因为“它用了C”，而是因为它绕过了 Python 解释器的运行时开销，并把计算压进连续内存 + 向量化指令这一条高效通路里。小数组（
为什么 np.array([1,2,3]) + np.array([4,5,6]) 不走 Python 循环
Python 的 + 对 list 是拼接操作，而 NumPy 重载了 __add__，实际调用的是底层 C 函数（如 PyArray_GenericBinaryFunction），输入是两个连续内存块的起始地址、长度、元素类型和步长（arr.strides）。整个加法在 C 层用指针偏移+循环完成，不创建任何 Python 对象，也不做类型检查。
- 验证方式：打印
arr.dtype，必须是int32、float64等标量类型，不能是object - 一旦含混合类型（如
np.array([1, 2.0, "x"])），会退化为objectdtype，所有运算回退到 Python 解释器层，速度反不如原生list - 临时数组分配也有开销：
a + b默认新建输出数组；高频场景可用np.add(a, b, out=result)复用内存
np.arange(1000000) ** 2 怎么避免解释器逐个判断幂运算合法性
因为 NumPy 在编译期就确定了操作可向量化——** 被映射到底层 pow 函数族（如 powf、pow），并由编译器自动展开为 SIMD 指令（AVX2 可一次处理 8 个 float64）。而 [x**2 for x in range(1000000)] 中每个 x**2 都要经过 Python 的对象查找、类型分发、运算符重载、结果封装四步。
- 关键前提：所有元素类型一致 + 操作无副作用（比如不调用
print()或修改全局状态） -
np.vectorize是假向量化——它只是把 Python 函数包装成“看起来像向量”的接口，底层仍是循环调用，别被名字骗 - 真正提速靠的是函数本身是否被 NumPy 内置支持：
np.sin、np.exp、np.log都走 SIMD；np.where带复杂条件表达式时，部分路径仍会 fallback 到解释器
为什么 list 即使存纯数字也快不起来
Python list 存的不是数字本身，而是指向 int 对象的指针。每个 int 对象有至少 28 字节头部（含引用计数、类型指针、值字段），且这些对象在堆上随机分布。CPU 缓存预取失效，每次访问都要解引用 + 类型检查 + 查找 __add__ 方法。
立即学习“Python免费学习笔记（深入）”；
- 对比内存布局：
np.arange(1000000, dtype=np.int64)占约 8MB 连续内存；等价list(range(1000000))实际占用 >32MB，且地址不连续 -
sys.getsizeof()看不到全部开销：它只统计容器本身，不包含所指对象的内存；真实内存压力来自缓存未命中（cache miss）导致的数百周期延迟 - 小数据场景（如 10~100 元素）中，NumPy 初始化开销（malloc 连续内存 + 设置
ndarray元信息）可能超过计算收益
真正决定 NumPy 是否快的，从来不是“用了没用 C”，而是你有没有让数据保持连续、类型单一、操作可并行——三者缺一，就掉回 Python 解释器层。别在循环里反复 np.array() 小列表，那是在给 GC 添堵。
