Numba加速需满足nopython模式、连续C-order数组、预分配内存等条件；若fallback至object mode或违反约束，反而比原生Python更慢。
Numba 能让 NumPy 数值计算快 10–200 倍，但前提是它真正“接管”了计算路径——不是加了 @jit 就自动加速，而是必须满足 nopython 模式、避免 Python 对象交互、用对数组访问方式。
为什么 @jit 有时没提速，甚至更慢？
常见错误是函数里混用了 Python list、dict、print、str 拼接或未类型化的变量。Numba 一旦 fallback 到 object mode（可通过警告 Compiling in object mode... 识别），就退化成带额外开销的解释执行，比原生 Python 还慢。
- 必须用
@njit或@jit(nopython=True)强制禁用 Python 解释器 - 所有输入参数必须是 NumPy 数组、标量或元组，不能是 pandas.Series、DataFrame、自定义 class
- NumPy 函数仅支持子集：如
np.sum、np.exp可用，但np.where带复杂条件或np.interp多数不可用 - 避免在循环内动态创建数组（如
np.array([...])），改用预分配 + 索引赋值
NumPy 数组传入 Numba 的关键约束
Numba 对数组内存布局敏感。若原始 NumPy 数组是非连续（如切片后未 .copy()）、非 C-order（Fortran order），@njit 会编译失败或静默降级。
- 确保传入的是 C-contiguous 数组：
arr = np.ascontiguousarray(arr) - 避免跨维索引如
arr[:, 0]直接传入；应先arr[:, 0].copy() - 多维数组优先用
arr[i, j]而非arr[i][j]（后者触发 Python 对象访问） - 不支持
arr[boolean_mask]高级索引，需改写为显式循环 + 条件判断
并行加速：用 nb.prange 替代 range
单核 JIT 加速有上限，而真实回测/模拟常含可并行维度（如遍历时间轴、通道、样本）。启用 parallel=True 后，Numba 会自动分块并调度到多核，但有隐藏前提：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 循环体必须无数据依赖（即第 i 次迭代不读/写第 j 次迭代的结果）
- 禁止在循环内修改全局变量或传入数组的 shape/dtype
- 累加类操作需用
nb.float64(0.0)显式声明类型，并用nb.parfor不支持的场景下改用线程局部变量 + 最终归约 - 首次调用仍需“冷启动”编译，建议用小数据预热：
_ = my_func(data[:100])
最容易被忽略的性能断点：内存分配与临时数组
NumPy 写法习惯用链式操作（如 (a + b) * c），看似简洁，实则每步都生成新数组。Numba 在 nopython 模式下无法优化这类表达式，反而因强制复制拖慢速度。
- 所有中间数组必须预分配：
out = np.empty_like(a)，再用循环或np.copyto - 避免
np.dot、np.matmul—— 它们底层调用 BLAS，无法被 Numba 并行化；改用嵌套循环手写点积 - 指数/三角函数等数学运算直接调用
np.exp、np.sin即可，Numba 已内置高效实现 - 若函数需多次调用且参数类型固定，用
@njit(cache=True)避免重复编译
真正卡住性能的往往不是算法逻辑，而是数组连续性、内存分配模式和并行边界这些细节。一个 @njit 函数从 890ms 降到 47ms，靠的不是魔法，是把每一步内存访问都控制在 CPU 缓存友好范围内。
