@jit装饰器仅在nopython=True模式下才可能实现C级加速，否则默认object模式几乎无提速；常见失效原因包括混用不支持的Python特性、未用NumPy替代标准库函数、类型推断失败等。
@jit 装饰器本身不会自动让 Python 代码达到 C 语言速度——它只在满足特定条件时才触发高效编译。盲目加 @jit 很可能无效，甚至报错。
为什么加了 @jit 却没加速？
最常见原因是函数内部混用了不支持的 Python 特性：nopython=True 模式（即真正高速模式）下，Numba 只认有限子集的 Python 语法和标准库。一旦遇到它无法编译的结构，就会回退到 object 模式（几乎无加速），或直接抛出 TyperError。
- 不支持
print()、list.append()、字典、类实例、字符串拼接等动态操作 -
random.random()不行，必须用np.random.rand()或显式传入随机数生成器 - 不能调用未被 Numba 支持的第三方函数（比如
scipy.special.gamma多数情况不支持） - 循环变量类型必须能被推断为标量（如
int64、float64），不能是None或混合类型
@njit 和 @jit(nopython=True) 是一回事吗？
是。二者完全等价：@njit 就是 @jit(nopython=True) 的简写。但注意：@jit 默认是 objectmode=True，也就是“尽力而为”模式，性能提升微乎其微。你必须显式写 @njit 或 @jit(nopython=True) 才能进入高速轨道。
- 写
@jit不带参数 → 默认 object 模式 → 基本不加速 - 写
@jit(nopython=True)或@njit→ 强制纯编译模式 → 加速生效前提 - 如果函数编译失败，
@njit会直接报错；@jit则静默降级，容易误判“已加速”
NumPy 数组操作必须用对方式
Numba 对 NumPy 的支持不是全量兼容，而是聚焦于数值计算核心路径。很多看似合理的写法会触发回退或错误。
- 支持：
arr[i]、arr.sum()、np.dot(a, b)、np.sin(x) - 不支持：
arr.tolist()、np.where(condition, x, y)（某些复杂 condition）、arr.reshape(-1)（-1 推断在旧版 Numba 中不稳定） - 推荐显式指定 dtype：
np.ones(1000, dtype=np.float64)，避免 Numba 推断出float32导致后续运算精度/兼容性问题 - 避免在循环内反复创建数组（如每次迭代
np.zeros(...)），应提前分配好内存并复用
第一次调用慢，之后才快 —— 这不是 bug
@njit 函数首次执行时要完成类型推断 + LLVM 编译，耗时可能比原 Python 版还长。这不是性能问题，而是 JIT 的固有开销。关键点在于：编译结果会被缓存，后续调用直接执行机器码。
立即学习“Python免费学习笔记（深入）”；
- 若输入类型变化（如第一次传
float64数组，第二次传int32），Numba 会重新编译一份新版本，产生额外延迟 - 可通过
@njit(cache=True)启用磁盘缓存，避免每次重启 Python 进程都重编译 - 生产环境建议用
cache=True+ 显式标注参数类型（如@njit("(f8[:], i4)")），减少运行时推断负担
nopython 模式、哪些会悄无声息地掉回 Python 解释器。一个 print() 调用就能让整段循环失去所有加速收益。 
