是的，readonly字段在单个对象构造函数内初始化时线程安全，但仅限构造完成且this未逃逸；若构造中泄露this或字段引用可变对象，则仍存在线程安全风险。
readonly 字段在构造函数中赋值时是线程安全的吗
是的，readonly 字段在**单个对象的构造函数内完成初始化**时，对该对象而言是线程安全的——但这个“安全”仅指：其他线程在该对象构造完成前无法访问它（除非你主动泄露 this），且 .NET 保证构造函数中对 readonly 字段的写入对后续所有读取可见（有内存屏障语义）。
关键前提是：构造必须真正完成，且对象引用不能在构造过程中逃逸。一旦构造函数返回，该对象就可能被多个线程同时访问，此时 readonly 只保证字段本身不能再被修改，不提供对字段所引用对象的线程安全保护。
构造过程中泄露 this 是最常见破环线程安全的场景
如果在构造函数里把 this 传给其他线程（比如启动 Task、注册事件、放入全局集合），那么另一个线程可能在构造尚未结束时就读取 readonly 字段——此时字段可能还是默认值（如 null 或 0），或处于中间状态。
- 不要在构造函数中调用虚方法（可能被子类重写并访问未初始化的
readonly字段） - 避免在构造函数中调用
Task.Run(() => { /* 使用 this */ }) - 避免将
this存入静态集合、并发字典或通过事件发布出去
public class BadExample
{
public readonly List<int> Data;
<pre class='brush:php;toolbar:false;'>public BadExample()
{
Data = new List<int>();
// ❌ 危险：this 泄露到其他线程
Task.Run(() => Process(this)); // 此时 Data 可能刚 new 出来，但还没填充
}
private void Process(BadExample obj) => Console.WriteLine(obj.Data.Count); // 可能为 0，也可能抛 NullReferenceException}
readonly 字段引用的对象本身不是线程安全的
readonly 修饰的是字段的“引用不可变”，不是其指向对象的内部状态。如果 readonly 字段是 List<int>、Dictionary<string, int> 或自定义可变类，多个线程仍可并发调用它的 Add()、Remove() 等方法，导致数据竞争。
-
readonly List<int> items = new();→items引用不能改，但items.Add(1)完全允许且非线程安全 - 需要线程安全集合？用
ConcurrentQueue<T>、ConcurrentDictionary<K,V>等 - 若必须用普通集合且只读访问，建议构造后调用
AsReadOnly()或封装只读接口（如IReadOnlyList<T>）
与 init-only 属性和 record 的对比要点
.NET 5+ 的 init 属性和 record 类型也强调“构造后不可变”，但它们没有 readonly 字段的内存可见性保障（除非配合 volatile 或显式屏障）。更重要的是：init 属性本质是 setter + 编译器检查，运行时无任何线程安全语义；而 readonly 字段由 JIT 和 CLR 在构造期间提供更强的发布保证。
如果你依赖多线程下“构造完就能安全读”，坚持用 readonly 字段 + 安全构造；别指望 init 或属性自动给你线程安全。
真正容易被忽略的是：线程安全从来不是某个关键字单独决定的，而是整个对象生命周期中引用是否逃逸、字段类型是否可变、以及外部同步策略共同作用的结果。一个 readonly 字段救不了泄露的 this，也护不住里面的 Dictionary。
