NumPy 2.5.0 自定义 dtype 调用 conjugate 报 non-numeric dtype

升级 NumPy 2.5.0 后，扩展库创建的数组调用 arr.conjugate() 或 arr.conj()，突然报：

TypeError: cannot conjugate non-numeric dtype

如果同一个数组交给 np.conjugate(arr) 却能正常计算，先检查扩展的 dtype 注册方式。这条回归影响的是一类沿用旧式注册接口的自定义 dtype，不表示数组里的数据真的变成了字符串，也不适用于所有同名 TypeError。

数组方法与 ufunc 没走同一条入口

NumPy 2.5 调整了数组方法的判断：结合 dtype 的虚部接口和数值标记，决定是否进入共轭运算。旧扩展可能已经为 np.conjugate 注册了计算循环，却没有设置这套新信息。数组方法提前把它判成非数值类型，根本没有调用已有的循环。

这也解释了为什么两个看起来等价的调用会出现不同结果。内置 complex 数组、自定义四元数数组和普通 object 数组不能混在一起判断。应保留扩展名称、版本、数组的实际 dtype，以及失败的是数组方法还是 ufunc；只打印几个元素的外观不够。

旧式 dtype 并非永远不能接入新接口。扩展作者可以按 NumPy 的版本和 API 条件设置相应槽位，关键是当前安装的扩展有没有完成这项适配。

NumPy 2.5.2 已恢复对这类旧式自定义 dtype 的兼容分派，2.5.4 也保留该分支。项目若需要继续使用 2.5 系列，应在 Python、扩展 wheel 和其他依赖都允许的范围内选用包含修补的正式版本，更新锁文件后再验证原调用。

不要只改依赖声明却继续运行旧环境，也不要把升级 NumPy 当作重新编译了第三方扩展。需要源代码构建的扩展，还必须具备它要求的工具链与兼容 API。

暂时不能更换依赖时，若扩展确实提供了有效的 conjugate ufunc 循环，可以在失败位置显式调用：

import numpy as np

# arr 是扩展库已经创建好的自定义 dtype 数组。
result = np.conjugate(arr)

这段替换只适合已经确认 ufunc 路径可用的数组。若它也报找不到循环、类型不能转换，继续检查扩展支持范围；不要用全局捕获 TypeError 后返回原数组来伪装成功。

四元数、有理数或其他自定义数值类型有自己的存储与运算含义。强制转成 float、取实部，或者把 dtype 换成 object，都可能丢失信息或改走另一套运算，不能作为通用修复。

在隔离环境中用扩展已知的数值样本比较原数组方法与 ufunc：结果值、dtype、形状及输入是否被改动都应符合扩展约定。有虚部的样本尤其必要，纯实数样本可能掩盖“直接返回输入”的错误。业务使用 out、非连续切片或批量运算时，再覆盖实际使用的形式。

保留升级前的依赖锁定和扩展产物。若需要回退，恢复的是整套兼容环境；已经保存的计算结果则按任务范围核查，恢复依赖不会自动重算它们。