LazyInitializer.EnsureInitialized 更轻量，因其不创建 Lazy 对象，直接在字段上原子赋值，避免状态机、委托封装及同步开销；适用于简单延迟初始化场景，但需注意异常缓存与闭包变量线程安全。
LazyInitializer.EnsureInitialized 为什么比 new Lazy() 更轻量
LazyInitializer.EnsureInitialized 不创建额外对象，直接在字段上做原子赋值；而 Lazy 是一个完整类，带状态机、委托封装和线程同步开销。当只需“首次调用时初始化一次”，且初始化逻辑简单（比如 new 一个对象），EnsureInitialized 更合适。
典型适用场景：静态只读字段、实例字段的延迟构造，尤其在高频访问但初始化成本高、又不希望引入 Lazy 对象分配的场合。
- 必须配合
ref参数使用，目标字段类型为T（不是Lazy） - 初始化委托
Func只会在第一次调用时执行，后续返回已存值 - 内部用
Interlocked.CompareExchange保证线程安全，无锁路径下性能接近普通字段读取
如何正确使用 EnsureInitialized 避免重复初始化或空引用
常见错误是把未初始化的字段传入后，又在外部判空再调用 —— 这会破坏原子性，导致多次初始化或竞态。正确做法是始终通过 EnsureInitialized 访问，不单独判空。
例如，以下写法危险：
if (_instance == null) // ❌ 竞态窗口：可能多个线程同时进入
{
_instance = CreateInstance();
}
应统一走 EnsureInitialized：
private static SomeService _instance;
private static readonly object _lock = new object();
public static SomeService Instance
{
get => LazyInitializer.EnsureInitialized(ref _instance, () => new SomeService());
}
- 字段
_instance声明为SomeService，不是Lazy - 初始化委托必须是纯函数（无副作用），否则重复执行会出问题（虽然实际不会重复，但逻辑上不能假设只跑一次）
- 如果初始化可能抛异常，异常会被缓存并每次重抛 —— 这点和
Lazy的IsValueCreated行为一致
EnsureInitialized 和 Lazy 在异常处理上的关键差异
两者都会缓存首次初始化时抛出的异常，并在后续访问时原样重抛。但 LazyInitializer 没有暴露类似 Lazy 或 Lazy 的状态查询机制，也无法区分“尚未初始化”和“初始化失败”。这意味着：一旦初始化委托抛异常，该字段将永远处于“失败态”，后续所有访问都直接抛同一异常。
- 无法重试：没有
Retry或重置方法，只能靠外部重建字段（如用volatile+ 手动锁） - 调试困难：异常堆栈指向
EnsureInitialized内部，需检查委托内代码 - 若需容错或重试逻辑，应改用
Lazy并捕获其Valuegetter 异常，或自行封装带重试的初始化逻辑
多参数初始化或依赖注入场景下怎么写
LazyInitializer.EnsureInitialized 只接受无参 Func，不支持直接传参。若初始化需要外部依赖（如 IOptions），必须提前捕获闭包变量。
private static MyProcessor _processor; private static IOptions_config; public static void Initialize(IOptions config) => _config = config; public static MyProcessor Processor => LazyInitializer.EnsureInitialized(ref _processor, () => new MyProcessor(_config.Value));
- 闭包变量（如
_config）必须在线程安全前提下被设置，否则可能捕获到 null 或旧值 - 避免在 lambda 中调用虚方法或可能被重写的成员，因初始化时机不确定，对象状态可能未就绪
- 若依赖项本身也是延迟初始化的，需确保其初始化顺序 ——
EnsureInitialized不提供依赖拓扑管理能力
