np.vectorize 不是真正 ufunc，因其仅为 Python 循环语法糖，无加速；真 ufunc 需 C 编译、支持广播与调度优化，推荐 numba.vectorize 显式声明 dtype 编译实现。
为什么直接用 np.vectorize 不算真正实现 ufunc？
很多人以为用 np.vectorize 包裹一个 Python 函数就得到了“自定义 ufunc”，其实不是。np.vectorize 只是语法糖，底层仍是 Python 循环调用，不加速，甚至更慢。真正的 ufunc 是 C 级别编译、支持广播、能被 NumPy 内部调度优化的函数。
如果你需要提速，必须走 np.frompyfunc + 类型标注 或直接用 numba.vectorize / cython 编译——前者更轻量，后者性能更强。
-
np.frompyfunc生成的是通用 ufunc，但返回 object 类型，需手动 cast，且不支持 dtype 推导 -
numba.vectorize支持target="cpu"或"parallel"，能生成原生 ufunc，且自动推 dtype - 如果函数含分支多、逻辑复杂，
numba可能 fallback 到 object 模式，这时要加@njit显式约束
用 numba.vectorize 写一个带 dtype 声明的 ufunc
这是目前最实用的路径：写纯 Python 函数 → 加 @vectorize 装饰器 → 显式声明输入输出类型 → 自动编译为 ufunc。
例如实现一个安全的除法（避免除零）：
立即学习“Python免费学习笔记（深入）”；
from numba import vectorize
import numpy as np
@vectorize(['float64(float64, float64)', 'int64(int64, int64)'])
def safe_div(a, b):
return a / b if b != 0 else 0.0
注意两点：
- 签名列表里必须覆盖你实际会传入的 dtype，否则运行时报
TypeError: No matching signature found - 不能在函数里用 list、dict、print 等非 numba 支持的操作，否则编译失败
- 第一次调用时编译，后续复用，所以首次调用略慢，但之后和原生 ufunc 速度一致
np.frompyfunc 的典型误用与绕过方法
直接用 np.frompyfunc(lambda x: x**2, 1, 1) 得到的函数，返回 dtype 是 object，后续计算会退化成 Python 对象操作，完全失去 NumPy 向量化优势。
真要用它，必须配合 .astype 强制转换，且仅适用于简单逻辑：
square_func = np.frompyfunc(lambda x: x**2, 1, 1) result = square_func(np.array([1, 2, 3, 4])).astype(int)
但这样仍比原生 **2 慢 10 倍以上。所以除非你必须调用某个无法 numba 化的外部库函数（比如某些 scipy 特殊积分），否则不推荐这条路。
- 常见错误：忘记
.astype，导致后续+或sum()变成 object 运算，报TypeError: unsupported operand type(s) - 兼容性差：
frompyfunc不支持out参数，也不能参与 ufunc 的 reduce/accumulate 等高级操作
ufunc 性能瓶颈常不在函数体，而在 dtype 和内存布局
即使你用 numba.vectorize 写对了，如果输入数组是非连续（如切片后未 copy）、dtype 不匹配或含 NaN，速度也会断崖下跌。
- 检查连续性：
a.flags.c_contiguous，不连续时先a.copy() - 避免混合 dtype：
safe_div(arr_int, arr_float)会触发隐式提升，可能慢于同 dtype 输入 - NaN 处理：Numba 默认不优化含
np.isnan的分支，建议用np.where预过滤，或改用np.errstate+ 原生 ufunc 组合
真正快的 ufunc，是类型干净、内存连续、逻辑扁平的组合；光靠“自定义”本身解决不了问题。
