record 和 init-only setter 不提供线程安全，仅保证编译期字段不可再赋值；若含可变引用类型（如 list），其内部状态仍可被多线程并发修改，需用 immutablecollections 并确保整个对象图不可变。
init-only setter 和 record 本身不提供线程安全，它们只是语法糖，不能自动保证多线程下的不变性。
record 的“不可变”仅指编译期构造后字段不可再赋值
record 类型在 C# 9 中默认生成 init 访问器（而非 set），意味着：一旦对象构造完成（即 new Person(...) 或 with 表达式返回后），所有 init 字段就无法被外部代码修改——这是编译器强制的语义约束，不是运行时锁或内存屏障。
但要注意：
- 这个约束只对
publicinit属性/字段生效；private set、internal init或反射仍可绕过 - 如果 record 包含可变引用类型（如
List<int></int>、Dictionary<string object></string>），其内部状态仍可在多线程中被并发修改 - record 的
Equals/GetHashCode是基于值生成的，但若内部集合被并发修改，可能导致哈希码突变、字典行为异常
init-only setter 不等于线程安全初始化
init setter 的本质是编译器将它翻译为一个带 [InitOnly] 特性标记的私有 setter，并在构造函数末尾调用。它解决的是“对象构建完成后禁止修改”的设计意图，不是“多个线程同时初始化一个实例”的同步问题。
典型误用场景：
- 多个线程同时 new 同一个 record 实例 → 没问题，各自独立对象
- 多个线程共享一个 record 实例，并试图通过反射调用
initsetter → 编译期不允许，但运行时可通过BindingFlags.NonPublic | BindingFlags.Instance强行调用，破坏不变性 - record 中包含
public readonly List<int> Items = new();</int>，然后多线程调用Items.Add(...)→ 完全合法且危险，List<t></t>本身不是线程安全容器
真正需要线程安全时该怎么做
如果你的 record 要在多线程环境中作为共享状态使用（比如缓存项、配置快照、事件载荷），必须额外处理可变子对象和发布安全性：
- 用不可变集合替代可变集合：改用
System.Collections.Immutable.ImmutableList<t></t>、ImmutableDictionary<k></k>，它们的修改操作返回新实例，天然适合 record 风格 - 确保所有嵌套类型也是不可变的：避免把
DateTime改成DateTimeOffset就算完事，重点是整个对象图没有可变引用点 - 若 record 实例需从非线程安全上下文构建（例如从数据库读取后填充），请在构造完成前确保所有字段已就绪——C# 不保证
init属性的赋值顺序跨线程可见，必要时加Volatile.Write或使用MemoryBarrier - 不要依赖 record 的
with表达式实现线程安全更新：它只是创建新实例，不解决“旧实例是否还在被其他线程使用”的生命周期问题
public record Person(string Name, ImmutableList<string> Tags)
{
// ✅ 安全：Tags 是不可变集合，Add 返回新实例
public Person WithTag(string tag) => this with { Tags = Tags.Add(tag) };
<pre class='brush:php;toolbar:false;'>// ❌ 危险：如果用 List<string>，下面这行会破坏线程安全
// public Person WithTag(string tag) { Tags.Add(tag); return this; }}
最常被忽略的一点：record 的“不变性”只到第一层字段。只要里面藏着一个可变对象，整个 record 就不是线程安全的不可变对象——这点和 Java 的 final 字段语义类似，但 C# 没有强制要求字段类型也必须不可变。
