加了@jit反而更慢，是因为函数混用python原生对象或不支持的库函数，触发numba回退到object mode，增加编译与类型推断开销；应改用@jit(nopython=true)并确保输入为numpy数组、避免list/dict/str等。
为什么加了 @jit 反而更慢？
直接给函数加 @jit 却没提速，甚至慢几倍，大概率是因为函数里混用了 Python 原生对象（比如 list、dict、字符串拼接）或调用了无法被 Numba 编译的库函数（如 math.log 而非 np.log）。Numba 在遇到不支持的操作时会自动退回到“object mode”，此时不仅没加速，还多了一层编译和类型推断开销。
实操建议：
- 用
@jit(nopython=True)强制启用严格模式，第一时间暴露不兼容代码 - 所有数值计算尽量走
numpy数组，避免for i in range(len(arr)):这类 Python 循环，改用for i in range(arr.size): - 函数参数类型要“干净”：只传
np.ndarray、标量（float64、int32）、元组（不可变），别传pandas.Series或自定义类实例
哪些函数适合加 @njit？
@njit 是 @jit(nopython=True) 的简写，它只接受 Numba 支持的子集——不是所有 NumPy 函数都行。常见可加速场景包括：纯数值循环（如向量点积、欧氏距离批量计算）、图像像素遍历、蒙特卡洛模拟内核、微分方程单步更新等。
典型可用操作：
- 数组索引与切片（
arr[i, j]、arr[1:-1]） - 基础运算（
+、*、**、np.sin、np.exp） - 循环结构（
for、while），但不能有break跳出多层嵌套（Numba 0.58+ 支持有限break） - 条件分支（
if/elif/else），但不能在条件中调用 Python 函数
典型禁用操作：print()、len()（对 list）、str.format()、np.linalg.solve()（需用 np.linalg.inv + 手动乘法替代）
如何调试 @njit 报错信息？
Numba 报错信息长且嵌套深，关键线索往往藏在最后一行，例如：TypingError: Failed in nopython mode pipeline (step: nopython frontend) — No implementation for function 'np.random.rand'。这说明你用了不支持的随机数生成方式。
实操建议：
- 把报错信息复制出来，搜索关键词 “
No implementation for function”，立刻定位不支持的函数 - 用
np.random.default_rng()创建生成器后传入函数，再调用其.random()或.integers()方法（Numba 0.57+ 支持） - 临时删掉部分逻辑，逐步缩小范围；也可加
@jit(forceobj=True)测试是否是类型问题（但别长期用） - 检查数组 dtype：
np.float32和np.float64不兼容，统一用np.float64更稳妥
第一次调用为啥特别慢？怎么预热？
@njit 函数首次执行时会触发编译，耗时可能达几百毫秒甚至秒级，尤其参数维度大或逻辑复杂时。这不是 bug，是 JIT 的固有行为。
缓解方法：
- 在程序初始化阶段，用典型小数据调用一次该函数，例如
my_func(np.ones(10), 2.0)，触发编译并缓存 - 用
@njit(cache=True)启用磁盘缓存（注意：函数签名变化后缓存失效，且 Windows 上路径权限可能出问题） - 避免在循环内部反复定义新
@njit函数（比如闭包里动态生成），会导致重复编译
缓存文件默认存在 __pycache__/numba_cache/ 下，可手动清理；若发现缓存没生效，检查函数是否引用了外部可变变量（如全局 list），这会让 Numba 拒绝缓存。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
