Pydantic 两个模型本来相等，读取缓存属性后却报数组真值错误

同样的两个 Pydantic 模型，第一次 a == b 返回正常，分别读取一个缓存属性以后，比较却变成：

ValueError: The truth value of an array with more than one element is ambiguous

如果缓存属性返回 NumPy 数组，先检查 functools.cached_property 是否把数组放进了实例的 __dict__。这条故障有 Pydantic 2.13.4 的明确环境，2.14.1 正式实现仍保留对应的快速比较路径。

BaseModel.__eq__ 会先检查类型、私有值和额外字段，再尝试整个实例字典相等；只有快速比较返回不等，才继续过滤普通字段。两个实例都缓存了不同的多元素数组对象时，字典比较可能要求把逐元素相等的数组结果转成单个布尔值，异常会在字段过滤之前抛出。

不需要缓存时，改成普通 property

如果派生数组生成成本可接受，可以不把结果缓存到实例字典：

import numpy as np
from pydantic import BaseModel, ConfigDict

class Measurement(BaseModel):
    model_config = ConfigDict(frozen=True)
    value: int

    @property
    def derived(self) -> np.ndarray:
        return np.array([self.value, self.value])

这个示例中，derived 不是模型字段，读取它不会新增同名的实例缓存项。代价是每次访问都重新构建数组，返回对象的身份也会改变；调用方若会修改该数组或依赖同一个缓存对象，需要先确认这种调整符合要求。

frozen=True 也不会阻止 cached_property 写入缓存，不能只靠冻结模型避开问题。把数组移到 PrivateAttr 也不能直接视为修复，因为 BaseModel 相等规则还会比较私有属性，可能再次遇到数组布尔值。

缓存必须保留时，明确业务上的比较键

若应用只是需要按某几个标量字段查重或分组，可以在该边界使用明确的比较键，例如单一模型类型中用 (model.value,)。这会把业务比较与派生缓存分开，但不是替换 BaseModel 全部相等语义的通用方案；不同模型类型、额外字段和私有状态是否应参与，需要按业务决定。

不要直接把 a == b 换成 np.all(a == b)：异常发生在模型比较内部，外层还没拿到可供归约的数组。也不能在捕获 ValueError 后一律返回 False，那会把本应相等的对象变成不等，还可能破坏字典键、集合和缓存的行为。

冻结模型的哈希与相等需要一起考虑。某些配置下两个对象的字段哈希相同，容器随后调用相等比较，仍会在查找时抛错。因此，检查范围不应只限于直接写出来的 a == b，还应包含应用实际的集合、字典键或 lru_cache 使用。

核对时分别覆盖双方都没读取缓存、只读一方、双方都已读取，以及字段相同和不同的组合。数组至少要有两个元素，单元素数组的布尔转换可能掩盖这条路径。若模型的真实字段本身就是数组，则需要另行定义数组字段的相等语义，不能沿用“只调整派生缓存”的结论。