LazyInitializer.EnsureInitialized适合手动控制初始化时机的轻量场景，它线程安全、不引入额外对象，但需用ref字段且不支持状态查询；Lazy<T>则封装完整延迟逻辑，适合需多次读取或暴露延迟能力的情况。
LazyInitializer.EnsureInitialized 适合手动控制初始化时机的场景
当你需要在某个方法内部、非构造函数中延迟初始化一个字段，又不想把整个对象包装成 Lazy<T> 时，LazyInitializer.EnsureInitialized 是更轻量的选择。它不引入额外对象，只做一次线程安全的赋值判断。
典型用法是配合一个 private T _field; 和一个 private object _lock = new object();，但注意：EnsureInitialized 自带锁机制，不需要你再写 lock —— 这点很多人误以为要配对使用。
- 它只负责“如果还没初始化，就调用工厂方法并赋值”，不保存工厂委托，也不跟踪是否已执行过
- 返回值是初始化后的实例，可直接用于后续逻辑，比如
return LazyInitializer.EnsureInitialized(ref _instance, ref _initialized, ref _lock, () => new ExpensiveService());
- 三个 ref 参数必须是类字段（不能是局部变量），否则编译报错：CS1503 “无法将 ref 参数转换为 ref 字段”
Lazy<T> 是完整封装的延迟初始化对象，自带状态和线程安全策略
Lazy<T> 本身是一个对象，封装了值、是否已初始化、初始化委托、以及线程安全模式（LazyThreadSafetyMode）。它适合需要多次读取、或想把延迟逻辑“暴露给调用方”的情况。
比如注入容器里注册一个 Lazy<IRepository>，让消费者按需触发创建；或者你想明确控制是“发布-订阅”式初始化（PublicationOnly）还是“首次访问即初始化”（ExecutionAndPublication）。
- 默认构造（无参数）等价于
new Lazy<T>(() => new T(), LazyThreadSafetyMode.ExecutionAndPublication) - 若传入
false构造，如new Lazy<T>(() => new T(), false)，则禁用线程安全，性能略高但需确保单线程调用 -
IsValueCreated属性可安全轮询状态，而EnsureInitialized没有对应的状态查询 API
常见误用：混用 ref 字段和属性，或误以为 EnsureInitialized 可重复调用工厂
下面这段代码会出问题：
private string _value;
private bool _initialized;
private readonly object _lock = new object();
public string GetValue()
{
// ❌ 错误：_value 是字段，但 _initialized 和 _lock 是字段——看起来对，但如果你不小心把 _initialized 写成属性：
// public bool Initialized { get; private set; } → 编译失败：不能 ref 属性
return LazyInitializer.EnsureInitialized(ref _value, ref _initialized, ref _lock, () =>
{
Console.WriteLine("init called"); // ✅ 只会打印一次
return "result";
});
}
另一个坑是认为 EnsureInitialized 会缓存委托结果供下次复用——它不会。每次调用都检查 _initialized，但工厂函数只执行一次。如果工厂函数有副作用（比如发 HTTP 请求），务必确认只期望执行一次。
- 不要对同一个
_initialized字段在多个方法里分别调用EnsureInitialized，否则可能竞态导致多次初始化（虽然极小概率，但违反语义） - 不要把
ref _lock换成typeof(T).GetHashCode()这类运行时计算值——锁对象必须稳定且唯一，否则线程安全失效
性能与内存开销差异很小，选型关键看职责边界
两者在 .NET Core 3.1+ 后性能几乎无差别：Lazy<T> 多一次对象分配，EnsureInitialized 多几个 ref 参数压栈。真正影响选择的是设计意图。
- 如果初始化逻辑只在当前类内部一处使用，且不想暴露“可延迟”语义，用
EnsureInitialized - 如果初始化逻辑需要被测试替换成 mock、或要跨层传递延迟能力（比如从 service 传到 controller）、或需要查询
IsValueCreated，用Lazy<T> - 不要为了“看起来更现代”而强行用
Lazy<T>包裹一个永远只读一次的字段——这增加了 GC 压力，也模糊了所有权
最易忽略的一点：二者都不解决“初始化失败后重试”问题。如果工厂抛异常，Lazy<T> 会缓存异常并每次重抛；EnsureInitialized 则把 _initialized 置为 true 并不再尝试——这意味着失败后该字段永远为 null 或默认值，且无提示。需要重试逻辑，得自己包一层。
