加了@jit反而更慢是因为首次调用需编译，且未启用nopython=True、类型未固定、存在Python对象交互或并行误用；应预热函数、显式声明类型、禁用动态特性并确保循环可并行。
为什么加了@jit反而更慢？先过“热身关”
第一次调用@jit函数时变慢，不是bug，是Numba在编译——类型推断、LLVM IR生成、机器码生成全在这一次完成。直接拿这个时间去比纯Python，等于拿汽车冷启动油耗去比自行车匀速能耗。
- 计时前必须先调用一次函数（哪怕传个最小数据），让编译完成
- 生产环境建议在服务启动时预热关键函数，避免用户首请求卡顿
-
cache=True能复用已编译版本，但首次仍需编译；若函数签名变化（如输入从float64变成float32），会触发新编译
nopython=True不是可选项，是加速前提
不加nopython=True（或等价的@njit），Numba就退化成“带缓存的解释器”，大部分优化失效，甚至因额外类型检查拖慢速度。
- 一旦启用
nopython=True，所有代码必须能被静态类型分析：不能用list.append()、不能调用Pandas/Scikit-learn方法、不能用print()调试 - 常见报错
TypingError: Failed in nopython mode，本质是某行代码Numba不认识——比如用了math.log而非np.log - 数组操作务必用
np函数：np.sqrt、np.exp、np.where，别用Python内置sqrt或**0.5
类型签名写死，才能榨干CPU性能
开发阶段用@jit自动推断很省事，但部署时必须显式声明类型签名。否则不同精度输入（如float32 vs float64）会触发多版本编译，磁盘和内存都吃紧。
- 推荐写法：
@jit("float64[:](float64[:], float64[:])", nopython=True)，明确输入输出类型和维度 - 整数运算慎用
int32：溢出无声发生，int64更安全；浮点运算统一用float64，避免float32累积误差 - NumPy数组必须用
[:]语法（如float64[:]），表示一维数组；二维用float64[:, :]，别写float64[:,:]（空格敏感）
并行加速不是开个开关就行
parallel=True只对可向量化循环有效，且要求循环体无数据依赖、不修改共享状态。盲目开启反而因线程调度开销变慢。
立即学习“Python免费学习笔记（深入）”；
- 确保循环内只读取数组、只写入独立索引位置（如
out[i] = ...），禁用out[0] += ...这类累加 - 配合
prange替代range：from numba import prange，否则Numba无法识别并行意图 - 小数组（ 计算收益，建议实测阈值
@jit，而是加了却没关掉Python对象交互、没锁死类型、没避开共享写入。这些细节不处理，百倍加速只会停留在宣传稿里。 
