@njit 加速源于编译为机器码并限制语法子集，不支持 python 对象、动态类型及多数标准库；报错因违反该子集规则，非装饰器本身导致提速。
为什么 @njit 有时比纯 Python 快 100 倍，但加了就报错？
根本原因不是“加了装饰器就自动变快”，而是 @njit 强制切换到 Numba 的编译子集——它不支持 Python 对象（如 list、dict、str）、动态类型、大部分标准库函数，甚至某些 NumPy 方法（比如 np.append 或带 axis=None 的 np.sum）。一旦函数体里出现不支持的语法或调用，Numba 就会抛出 TyperError 或 LoweringError，而不是静默回退。
实操建议：
- 先确保输入是
numpy.ndarray，且 dtype 明确（推荐float64或float32），避免传入list或pd.Series - 函数内部只用基础循环、
numpy的 ufunc（如np.sin、np.exp）和有限的数组操作（a[i]、a.reshape、a.copy()） - 首次调用时会触发编译（有延迟），可加
cache=True缓存编译结果：@njit(cache=True) - 调试阶段用
@njit(nogil=True, debug=True)能暴露更具体的类型错误位置
@vectorize 和 @njit 该选哪个？
二者目标不同：@vectorize 是为单个标量函数生成 NumPy 风格的向量化版本（类似 np.vectorize，但真编译）；@njit 是直接编译整个函数，支持循环、分支、多维索引等完整逻辑。
常见误用场景：
- 想对两个数组逐元素相乘再求和 → 用
@njit写显式循环，别用@vectorize+ Pythonsum()（后者无法被编译） - 想把一个数学公式（如
sin(x) * exp(-x**2)）应用到整个数组 →@vectorize更简洁，且能自动处理广播 -
@vectorize默认返回新数组，不支持原地修改；若需 in-place 运算（如更新大数组某列），必须用@njit
性能提示：对简单标量运算，@vectorize 和 @njit 差距不大；但涉及条件分支、累积计算（如前缀和）、或需复用中间变量时，@njit 是唯一选择。
为什么开了 nogil=True 却没提速，甚至更慢？
nogil=True 允许 Numba 函数绕过 Python GIL，在多线程中并行执行。但它只在函数真正“密集计算”且不频繁调用 Python C API 时生效。如果函数里混了 print()、len()、range()（非 numba.prange）或任何隐式 Python 对象操作，Numba 会自动降级为带 GIL 模式，此时 nogil=True 不仅无效，还增加调度开销。
正确做法：
- 循环必须用
numba.prange替代range，否则无法并行 - 禁用所有 I/O、类型检查、异常抛出（
try/except在@njit中非法） - 确认 CPU 利用率：运行时用
htop或任务管理器看是否真起了多核；若只有 100% 单核，说明并行没生效 - 小数组（
GPU 加速（@cuda.jit）真的适合你的计算吗？
不是所有浮点运算都适合上 GPU。@cuda.jit 要求你手动管理设备内存（cuda.to_device / .copy_to_host()）、显式定义线程块结构（blockspergrid, threadsperblock），且只对大规模、高度并行、计算密度高（FLOPs / byte）的任务有收益。
典型不适用场景：
- 数组尺寸小于 10⁵ —— 数据拷贝开销压倒计算收益
- 存在复杂控制流（大量
if-else分支）或不规则内存访问（如稀疏矩阵索引） - 依赖 NumPy 特有行为（如
np.nan传播规则、np.where的三元语义）
更现实的路径：先用 @njit(parallel=True) 在多核 CPU 上跑通，确认瓶颈确实是计算而非 I/O；再评估是否值得引入 CUDA 环境和重构内存模型。
最后提醒一句：Numba 编译结果高度依赖输入类型。同一个函数，传入 float32 和 float64 数组会生成两套独立机器码。别指望一次编译适配所有 dtype——该显式标注就标注，该分拆就分拆。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
