因为 hash 与 eq 必须保持一致性：若 eq 忽略某字段而 hash 未同步忽略，会违反“相等对象哈希值必须相同”的契约，导致哈希表异常或崩溃。
为什么 hash 和 eq 一起用时字段忽略会失效
因为大多数语言的默认 hash 实现（如 Python 的 __hash__、Rust 的 Hash trait、Java 的 hashCode()）和 eq（__eq__ / PartialEq / equals()）是强耦合的：如果两个对象 eq 返回 True，它们的 hash 值**必须相等**。一旦你手动忽略某个字段做 eq 比较，但没同步从 hash 计算中剔除它，就会违反这个契约——轻则哈希表行为异常（查不到、重复插入），重则引发不可预测的崩溃或静默错误。
Python 中手动实现 __eq__ 和 __hash__ 时忽略字段
核心原则：参与 eq 判断的字段，**必须且仅能**是参与 hash 计算的字段。要“忽略”某个字段，就得在两者中都排除它。
-
__eq__里只比较你关心的字段，比如self.id == other.id and self.name == other.name，跳过self.updated_at -
__hash__必须只基于相同字段计算，例如return hash((self.id, self.name))，绝不能包含self.updated_at - 如果类可变（字段后续会被修改），不要实现
__hash__（或显式设为None），否则哈希值变化会导致字典/集合失效
示例：
class User:
def __init__(self, id, name, updated_at):
self.id = id
self.name = name
self.updated_at = updated_at # 忽略此字段
def __eq__(self, other):
if not isinstance(other, User):
return False
return self.id == other.id and self.name == other.name
def __hash__(self):
return hash((self.id, self.name))
Rust 中用 #[derive(PartialEq, Eq, Hash)] 但跳过某些字段
Rust 的派生宏默认包含所有字段。要忽略，得用 #[hash(serialize_with = "...")] 这类方式不现实；正确做法是**不 derive，手写实现**，或借助 serde 风格的宏（如 derive_more）配合属性标记。
- 最稳妥的是手动实现
PartialEq和Hash，只对目标字段调用eq和hash方法 - 若用
derive_more::Hash，需配合#[derive_more::skip]属性（注意：不是标准库支持，需引入derive_morecrate） - 字段类型本身必须满足
Hash + Eq，否则编译失败
手写片段示意：
impl PartialEq for User {
fn eq(&self, other: &Self) -> bool {
self.id == other.id && self.name == other.name
}
}
impl Eq for User {}
impl Hash for User {
fn hash(&self, state: &mut H) {
self.id.hash(state);
self.name.hash(state);
}
}
Java 里重写 hashCode() 和 equals(Object) 的常见翻车点
IDE 自动生成的代码常把所有字段都塞进去，但“忽略字段”不是删掉一行就完事——必须保证两方法逻辑完全对齐，且遵守对称性、传递性、一致性约束。
- 检查
equals中是否用了==比较引用类型（如String应用.equals()） -
hashCode()中被忽略的字段，绝对不能出现在Objects.hash(...)参数列表里 - 如果字段可能为
null，equals要先判空，hashCode()要用Objects.hashCode(field)避免 NPE - 使用 Lombok？加
@EqualsAndHashCode(onlyExplicitlyIncluded = true)，再对要保留的字段标@EqualsAndHashCode.Include
容易被忽略的是：即使字段被忽略，只要它参与了对象生命周期中的状态变更（比如缓存 key 依赖它），仍可能导致业务逻辑错乱——hash 和 eq 只管容器行为，不管语义。
