LazyInitializer.EnsureInitialized 为什么比 new Lazy() 更轻量
LazyInitializer.EnsureInitialized不创建额外对象，直接在字段上做原子赋值；而
Lazy<t></t>是一个完整类，带状态机、委托封装和线程同步开销。当只需“首次调用时初始化一次”，且初始化逻辑简单（比如 new 一个对象），
EnsureInitialized更合适。
典型适用场景：静态只读字段、实例字段的延迟构造，尤其在高频访问但初始化成本高、又不希望引入
Lazy<t></t>对象分配的场合。 必须配合
ref参数使用，目标字段类型为
T（不是
Lazy<t></t>） 初始化委托
Func<t></t>只会在第一次调用时执行，后续返回已存值 内部用
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<someservice></someservice>初始化委托必须是纯函数（无副作用），否则重复执行会出问题（虽然实际不会重复，但逻辑上不能假设只跑一次） 如果初始化可能抛异常，异常会被缓存并每次重抛 —— 这点和
Lazy<t></t>的
IsValueCreated行为一致
EnsureInitialized 和 Lazy 在异常处理上的关键差异
两者都会缓存首次初始化时抛出的异常，并在后续访问时原样重抛。但
LazyInitializer没有暴露类似
Lazy<t>.IsValueCreated</t>或
Lazy<t>.Value</t>的状态查询机制，也无法区分“尚未初始化”和“初始化失败”。这意味着：一旦初始化委托抛异常，该字段将永远处于“失败态”，后续所有访问都直接抛同一异常。 无法重试：没有
Retry或重置方法，只能靠外部重建字段（如用
volatile+ 手动锁） 调试困难：异常堆栈指向
EnsureInitialized内部，需检查委托内代码 若需容错或重试逻辑，应改用
Lazy<t></t>并捕获其
Valuegetter 异常，或自行封装带重试的初始化逻辑
多参数初始化或依赖注入场景下怎么写
LazyInitializer.EnsureInitialized只接受无参
Func<t></t>，不支持直接传参。若初始化需要外部依赖（如
IOptions<myconfig></myconfig>），必须提前捕获闭包变量。
private static MyProcessor _processor;
private static IOptions<MyConfig> _config;
public static void Initialize(IOptions<MyConfig> config) => _config = config;
public static MyProcessor Processor =>
LazyInitializer.EnsureInitialized(ref _processor, () => new MyProcessor(_config.Value));
闭包变量（如 _config）必须在线程安全前提下被设置，否则可能捕获到 null 或旧值 避免在 lambda 中调用虚方法或可能被重写的成员，因初始化时机不确定，对象状态可能未就绪 若依赖项本身也是延迟初始化的，需确保其初始化顺序 ——
EnsureInitialized不提供依赖拓扑管理能力 实际用的时候，最容易被忽略的是异常缓存行为和闭包变量的生命周期管理。这两个点不注意，线上可能表现为“服务启动后首次调用必失败，之后一直失败”，而不是预期的“失败后下次重试成功”。
