NumPy 明明显示 float64，linalg 却说不支持这个类型

Windows 上运行线性代数运算，数组打印出来是 dtype=float64，异常却也是：

TypeError: array type float64 is unsupported in linalg

若问题随导入顺序变化，尤其先导入某个会查询 np.finfo(np.longdouble) 的库后才出现，应检查 finfo 缓存返回的标量类型。数组的 dtype 名称在这个场景里不足以区分它真正使用的 NumPy 标量类型。

明确记录过的受影响组合包括 Windows AMD64 上的 NumPy 2.4.0、2.4.4、2.5.0 和 2.5.3。2.5.4 正式实现仍使用相关缓存逻辑；不能只凭版本高于 2.5.3 就排除这条路径。

看 dtype.type，也看阈值的 type

在 Windows 的相关构建中，longdouble 与 float64 的存储尺寸相同，两个 dtype 可以比较相等并有相同哈希。但它们对应的 NumPy 标量类型仍不同。

旧的 finfo 缓存只按 dtype 查找。先查询 longdouble，后查询 float64，可能取得同一个缓存对象，使后者的 eps 实际成为 np.longdouble。与这个强类型标量做运算后，原本的 float64 数组也可能被提升成 longdouble，随后被 numpy.linalg 拒绝。

在已有故障进程里，可以对需要进入线性代数运算的数组和阈值做少量类型检查。下面的 values 指实际运算输入，不是要求另建一个必然相同的环境：

print(values.dtype)
print(values.dtype.type)
print(type(eps))

如果名称显示 float64，但 values.dtype.type 或阈值类型是 np.longdouble，再回查产生 eps、tiny 等阈值的代码，以及此前的 finfo 调用。只记录必要类型，不打印业务数组内容。

不要把所有平台归为同一结果。macOS arm64 也可能存在 dtype 缓存别名，但具体阈值标量不一定变成 longdouble；Linux 上较宽的 longdouble 又是另一组条件。平台、构建与实际类型都要保留。

在需要双精度的边界明确阈值类型

应用本来只需要 float64 时，可以在把阈值用于数组运算之前，明确转换成 float64 标量。例如这段局部处理片段：

import numpy as np

# 应用已决定这里采用 float64 精度。
eps = np.float64(np.finfo(np.float64).eps)
values = np.asarray([1.0, 2.0, 3.0], dtype=np.float64)
clipped = np.clip(values, eps, np.inf)

随后核对 clipped.dtype.type 是否为预期的 np.float64，再进入原来的线性代数运算。示例只处理一个阈值；依赖内部使用了其他常量或已经提升过的中间数组时，还要找到真正的类型传播边界，不能在入口加一行便认为全部恢复。

如果业务确实依赖更高精度，不应为了让 numpy.linalg 接受而悄悄降成 float64。先确认所用平台是否提供更宽精度，再选择支持目标类型的计算路径和误差标准。

调整导入顺序只能解释现象

先查询一次 finfo(float64)，可能改变缓存最先保存的对象，暂时避开错误。但另一个插件或库提前导入，就可能再次改变顺序。不要把这个先后顺序写成长期稳定的接口约定，也不要直接清空或改写 NumPy 私有缓存。

缓存键区分不同 dtype 类的修复已进入主线；截至 2026 年 10 月 22 日核对的正式稳定版仍为 2.5.4，不能把主线合并或后续版本里程碑写成已发布修复。采用后续发行版时，应核对它实际包含的实现及项目支持范围。

修改前保存依赖锁文件和类型记录。验收要在原来的 Windows 构建中覆盖两种导入顺序，并检查真正失败的拟合或求解任务、结果精度和异常路径。若局部阈值改动没有覆盖依赖内部的类型传播，保留证据继续定位，不要用吞掉 TypeError 或随机替换 BLAS 来掩盖它。