默认的==和equals()对自定义引用类型默认比较引用而非值，故字段相同也返回false；必须重写equals(object)和gethashcode()并推荐实现iequatable，否则dictionary等集合行为异常，record可自动实现但仅适用于不可变数据场景。
直接说结论：默认的 == 和 Equals() 对自定义引用类型几乎总是返回 false，哪怕字段值完全一样；真想按内容比较，必须重写 Equals(object)、GetHashCode()，并考虑实现 IEquatable<t></t>。
为什么 == 和 ReferenceEquals 不适合内容比较
对普通 class（非 record），== 默认做引用比较，和 Object.ReferenceEquals(a, b) 行为一致 —— 只有 a 和 b 指向同一内存地址才返回 true。这在大多数业务场景下不是你想要的。
-
ReferenceEquals(1, 1)返回false：值类型传入会装箱，生成两个不同对象 -
ReferenceEquals(null, null)返回true：这是唯一允许的 null 安全用法 - 重载了
==的类型（如string、record）是例外，但你不该依赖它作为通用方案
重写 Equals(object) 的硬性要求
只改 Equals(object) 是不够的，而且容易出错。必须同步处理三个关键点：
- 先做
null和类型检查：if (obj == null || GetType() != obj.GetType()) return false; - 强制转型后逐字段比较（注意值类型字段可直接 ==，引用类型字段要递归调用
Equals()） - 必须重写
GetHashCode()：否则放进Dictionary或HashSet会行为异常 —— 相等对象必须返回相同哈希码
漏掉 GetHashCode() 是最常被忽略的坑，会导致集合查找失败或重复插入。
为什么要实现 IEquatable<t></t>
这是给泛型集合（如 List<t>.Contains()</t>、Dictionary<tkey tvalue></tkey>）用的优化接口。不实现它，泛型方法内部仍会走 object.Equals()，触发装箱（对 struct）或反射（对 class）。
- 实现后，
list.Contains(item)能直接调用你写的Equals(T other)，零开销 - 接口方法签名是
bool Equals(T other)，无需类型判断和转型 - 记得让
Equals(object)内部也调用Equals(T)，保持逻辑统一
record 类型是个特例，但别滥用
C# 9+ 的 record 默认启用基于值的相等语义，自动重写 Equals、GetHashCode、==，连 with 表达式都支持。
- 适合不可变数据载体（DTO、消息体），比如
record Person(string Name, int Age); - 不适合含复杂状态、生命周期管理或需要自定义比较逻辑的类（比如带缓存、事件订阅、IDisposable 的类型）
- 一旦用了
record，就无法再继承普通 class，设计约束变强
真正难的不是写对 Equals，而是判断「这个类型到底该不该支持值相等」——很多所谓“相等”的需求，其实应该用明确的业务规则方法（如 IsSameCustomerAs()）来表达，而不是塞进通用的 Equals。
