record的hashCode基于字段值调用Objects.hash，按声明顺序传参，支持泛型、null安全，但要求字段类型自身正确实现hashCode，且不可在紧凑构造器中修改final字段。
Record 就是为这事设计的：用一行声明替代手写 equals、hashCode、构造器和 getter，且生成的 hashCode 是基于字段值的 Objects.hash(...) 调用，无反射、无运行时开销，天然高效。
record 的 hashCode 是怎么算出来的
编译器在生成字节码时，会把 record 所有组件（字段）按声明顺序传给 Objects.hash。比如：
record User(String name, Integer age, List<String> roles) {}
它的 hashCode 等价于：
return Objects.hash(name, age, roles);
这意味着：
-
Objects.hash对基本类型直接取值，对引用类型调用其hashCode()—— 所以嵌套 record 或标准集合（如ArrayList、ImmutableList）都能正确参与哈希计算 - 如果某个字段是自定义类（非 record），必须确保它自己重写了
hashCode，否则可能返回0或默认System.identityHashCode - 字段为
null时，Objects.hash安全处理，不会 NPE - 字段越多，参数列表越长，但仍是 O(1) 时间复杂度，无对象分配
泛型字段必须显式写出类型参数
record 不做类型推断，擦除后无法还原泛型信息，这直接影响 hashCode 的一致性：
- ✅ 正确：
List<string> roles</string>→roles.hashCode()被调用，内容参与哈希 - ❌ 错误：
List roles→ 擦除为原始类型List，roles.hashCode()可能只反映引用地址（取决于具体实现），导致相同逻辑数据产生不同哈希值 - ⚠️ 特别注意：
Map<k v></k>、Optional<t></t>、Set<x></x>同理，漏写泛型参数 = 放弃哈希语义保障
紧凑构造器里不能改字段值，否则破坏哈希一致性
紧凑构造器（public User { ... }）允许校验，但禁止赋值操作。一旦你试图“归一化”字段，比如：
publicrecord User(String name) {
publicUser {
// ❌ 编译错误：Cannot assign a value to final variable 'name'
this.name = name.trim();
}
}
这么做不仅非法，更危险的是：如果绕过编译器强行做到（比如用反射），会导致 name() 返回的值与 hashCode 计算时用的原始参数不一致，从而破坏哈希契约 —— 同一实例多次调用 hashCode() 可能返回不同结果，或两个逻辑相等的实例哈希值不同。
真需要归一化（如 trim、unmodifiable 包装），应改用规范构造器（canonical constructor），显式声明并调用 this(...)：
publicrecord User(String name) {
publicUser(String name) {
this(name == null ? null : name.trim());
}
}
但要注意：这会放弃部分自动生成逻辑（比如编译器不再为你生成那个隐式构造器），需自行权衡。
序列化和 hashCode 的隐性依赖
record 默认不实现 Serializable，但很多场景（如缓存、RPC）要求可序列化。若你加了 implements Serializable，要意识到：
- 字段类型本身必须可序列化；否则反序列化后字段为
null，hashCode结果就和序列化前不一致 - Jackson 2.12+ 默认支持 record，但若字段是
final集合（如List.of(...)），反序列化时可能创建新实例，只要其hashCode实现正确，不影响 record 层面的一致性 - 不要依赖
serialVersionUID来“稳定”哈希值 ——hashCode由字段值决定，跟序列化版本号无关
最易被忽略的一点：record 的 hashCode 高效，但前提是字段类型自身高效。如果某个字段是 10MB 的 byte[] 或深度嵌套的 record 树，hashCode 调用就会变慢 —— 这不是 record 的问题，而是数据建模该收敛的地方。
