record 类型最直接的好处是：用一行声明自动获得不可变性、值相等、安全克隆和可读字符串表示——省掉 90% 的 DTO/VO 样板代码。
为什么不用 class 写 DTO？
手动写
class实现数据传输对象时，你得反复处理：
get; init;属性、构造函数、
Equals、
GetHashCode、
ToString，甚至还要考虑线程安全。稍不注意就写出可变对象，在并发或 API 层埋下隐患。 改一个属性可能意外影响其他模块（比如被某个
foreach循环中的引用悄悄修改） 两个相同内容的
class实例用
==比较返回
false，但业务上它们就是“相等”的 想复制并改一个字段？得手写
Clone()或深拷贝逻辑，容易漏字段或出错
record 怎么解决这些痛点？
它不是语法糖，而是编译器级契约：一旦声明为
record，你就默认获得四项关键能力。
init属性强制只在初始化阶段赋值（包括
new和
with表达式），运行时修改直接报错：
Init-only property or indexer 'X.Y' can only be assigned in an object initializer...两个
record实例只要所有公开属性值相同，
==、
.Equals()、
.GetHashCode()全部自动对齐——无需重写
with表达式提供非破坏性更新：
var p2 = p1 with { Age = 31 };，生成新实例，原对象毫发无损
ToString()输出结构化文本：
Person { Name = "Alice", Age = 30 }，调试时一眼看清状态
哪些场景必须优先用 record？
不是所有类都适合 record，但它在以下场景几乎无替代方案：
Web API 的请求/响应模型（DTO）：避免反序列化后被意外修改，也防止前端传参污染服务端状态 领域驱动设计中的值对象（Value Object）：如Money、
Address、
Range<int></int>，语义上“值相同即相等” 并发计算中的中间数据：比如 LINQ 查询链、Actor 模型消息体、函数式风格管道处理，天然线程安全 配置快照或日志事件结构：记录某一时刻的状态，绝不允许事后篡改
容易忽略的坑和限制
record 看似简单，但几个边界问题常被低估：
继承只能在record之间进行：
public record Animal : Person✅，但
public record Dog : SomeClass❌ 编译失败 位置记录（
public record Person(string Name, int Age)）会自动生成
Deconstruct方法，但如果你手动加了
private set属性，它不会参与
Equals计算——这点和
init属性不同 record 是引用类型，不是 struct；它不触发栈分配，也不带值类型的内存拷贝开销，但也不能用
ref参数做原地修改 如果真需要部分可变（比如缓存字段），可以用
private readonly字段 + 公开
init属性组合，但要清楚这已偏离纯 record 语义
真正难的不是写
record，而是判断什么时候不该用它——比如需要生命周期管理、事件通知、延迟加载或复杂验证逻辑的对象，还是老实用
class更合适。别为了“简洁”牺牲语义清晰度。
