@njit 比 @vectorize 更快可控，因其编译整函数为机器码，支持分支循环与内存控制；而 @vectorize 仅适用于标量映射，遇条件逻辑易退化。
为什么 @njit 有时比 @vectorize 更快且更可控
因为 @njit 编译整个函数为机器码，支持分支、循环、自定义类型和内存布局控制；而 @vectorize 本质是自动广播的 ufunc，仅适用于标量输入/输出的纯映射操作，遇到条件逻辑或中间数组就容易出错或退化为 Python 解释执行。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
@njit处理含for循环、if判断、多步中间计算的复杂数学逻辑（如迭代求解、分段函数、自定义卷积） - 避免在
@njit函数里调用未编译的 NumPy 高阶函数（如np.linalg.solve、np.fft.fft），它们会触发 object mode 回退，性能暴跌 - 显式声明返回类型（如
@njit("float64[:](float64[:], float64)")）可减少类型推断开销，尤其在首次调用时
如何让 Numba 正确处理复数运算和广播维度
Numba 默认不支持复数的高级广播（比如 (n, m) + (m,)），且部分复数函数（如 np.angle、np.conj）需用 numba.np.numpy_support 或手动展开。常见错误是直接传入带复数的高维数组后报 TypingError: cannot determine Numba type of <class></class>。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
np.complex64或np.complex128显式指定 dtype，避免 Python 复数对象混入 - 对广播需求，先用 NumPy 做 shape 对齐（如
a[:, None] + b[None, :]），再传给@njit处理已展开的数组 - 复数相位、模长等运算，改用
np.abs(x)、np.real(x)、np.imag(x)—— 这些在@njit中完全支持；但np.angle(x)不支持，需用np.arctan2(np.imag(x), np.real(x))
遇到 LoweringError 或 TypingError 怎么快速定位
这类错误通常不是代码语法错，而是 Numba 在类型推导或底层 IR 生成阶段失败。最常触发的点：用了不支持的 NumPy 方法、嵌套 list、动态 shape、或传入了非 NumPy 数组（如 Pandas Series、Python list）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 加
cache=True和error_model="numpy"参数（如@njit(cache=True, error_model="numpy")），前者加速重复调用，后者让浮点异常行为更贴近 NumPy - 运行前用
inspect_types()查看类型推断结果：my_func.inspect_types()，重点关注标量类型是否被识别为int64而非pyobject - 临时把函数体简化为只返回一个常量（如
return 1.0），再逐步加回逻辑，能快速锁定哪一行引入了不支持的操作
什么时候该放弃 Numba 改用 Cython 或原生 C
当你的“复杂运算”涉及大量内存分配（如频繁创建新数组）、递归、或依赖外部 C 库（如 FFTW、LAPACK），Numba 的限制就会明显：它不支持 malloc、不能直接调用任意 C 函数、也不允许在 jit 函数中用 with 或 try/except。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 如果核心循环里有
np.zeros()/np.empty()调用超过 2–3 次，且无法预分配，优先考虑 Cython + memoryview - 已有成熟 C 实现？用
ctypes或cffi封装比硬写@njit更稳，尤其涉及指针运算或回调函数时 - 调试成本高：Numba 报错堆栈深、提示模糊；Cython 错误位置明确，且支持 pdb 单步 —— 算法还在快速迭代时，别过早锁死在 Numba 上
@njit 函数可能比原始 NumPy 还慢，因为隐式回退到了 object mode —— 这点很容易被忽略，但决定了你花半天调参值不值得。 
