@njit有时变慢是因为混用Python原生对象或NumPy高层接口导致退化为object mode；需确保参数全为Numpy数组/标量、启用fastmath和cache、避免首次计时、用inspect_types验证nopython模式。
为什么 @njit 有时不加速反而变慢？
直接加 @njit 并不能保证提速，尤其当函数里混用 Python 原生对象（如 list、dict、str）或频繁调用 NumPy 高层接口（如 np.append、np.concatenate）时，Numba 会退化为 object mode，甚至比纯 Python 还慢。
实操建议：
- 用
@njit(fastmath=True, cache=True)显式启用快速数学模式和磁盘缓存，避免重复编译 - 函数参数必须全是 Numpy 数组或标量（
int64、float64等），不能是list或tuple（哪怕内容是数字） - 首次运行会触发编译，测速别计第一次耗时；可用
inspect_types()查看是否进入 nopython mode - 若报错
TypingError: cannot determine Numba type of <class></class>，说明传了 Python list —— 改用np.array(my_list)预转换
如何处理带条件分支和循环的数值计算？
Numba 对 for 循环、if/elif/else 支持良好，但要求所有分支路径返回类型一致，且不能有未定义变量（比如只在 if 里赋值、else 里没赋的变量）。
常见错误现象：运行时报 InternalError: unsupported control flow 或结果为 nan。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 避免在循环内动态改变数组长度（如边算边
append）；提前用np.empty()分配固定大小缓冲区 - 多维索引要显式写成
a[i, j]，别用a[(i, j)]或a[[i, j]] - 如果逻辑复杂，拆成多个
@njit函数，主函数只做调度，计算密集部分单独编译 - 支持
prange并行循环，但需加parallel=True参数且确保无数据竞争；简单累加记得用np.sum()而非手写并行 reduce
@vectorize 和 @guvectorize 适合什么场景？
@vectorize 是对标量函数的自动广播封装，适合“一个输入标量 → 一个输出标量”的情况（如自定义 sigmoid）；@guvectorize 则控制输入/输出维度签名，适合需要保持特定轴对齐的操作（如滑动窗口、矩阵行归一化）。
性能差异明显：前者底层仍是逐元素调用 njit 函数，后者可生成真正向量化机器码。
实操建议：
- 用
@vectorize(['float64(float64)'], target='cpu')时，签名必须覆盖所有实际输入类型，否则回退到 Python 模式 -
@guvectorize的signature字符串如(n)->(n)表示输入一维长 n，输出也一维长 n；若写成(n)->()就是压缩求和，此时函数体内必须给输出标量赋值（如out[0] = np.sum(inp)） - 两者都不支持
return，结果必须写入out参数；忘记写会导致输出全零或未初始化内存值
调试 @njit 函数时看不到中间变量怎么办？
Numba 编译后无法用 print() 或 logging，pdb 也进不去。最有效的调试方式是先在纯 Python 下跑通逻辑，再逐步加 @njit 并用 inspect_types() 验证类型推断。
实操建议：
- 把核心计算逻辑抽成独立函数，先不加装饰器，单元测试通过后再加
@njit - 用
my_func.inspect_types()输出类型信息，重点检查每行是否显示type: float64而非type: pyobject - 临时把
@njit换成@njit(nopython=False)强制 object mode，能跑通但不加速 —— 可用来定位哪行触发降级 - 数组切片要小心：
a[1:]在 nopython mode 下是允许的，但a[a > 0]（布尔索引）不支持，得改用np.where()+ 显式索引
