应避免手动实现双重检查锁单例，.net 4.0+ 优先用 lazy（需静态字段+异常处理），旧框架用静态构造函数；lazy 不支持异步，需异步初始化时改用 asynclazy 或 task 封装；慎用全局单例，优先考虑 di 的 scoped 生命周期。
为什么不用 lock + 双重检查就别碰单例
手动用 lock 和 if (instance == null) 套两层判断，看似稳妥，实则极易出错：忘记加 volatile 修饰字段会导致指令重排，.NET 4.0 之前还可能因 JIT 优化让未初始化对象被其他线程看到。这不是理论风险——真实项目里出现过构造函数没跑完、instance 却已非 null 的诡异 crash。
实操建议：
- 绝对不要自己手写双重检查锁（Double-Checked Locking）
- .NET 4.0+ 直接用 Lazy<t></t>，它底层已处理内存屏障和线程同步
- 若必须兼容旧框架（如 .NET 3.5），改用静态构造函数方式，靠 CLR 保证只执行一次且线程安全
Lazy 初始化失败时怎么捕获异常
Lazy<t></t> 默认是“第一次访问 Value 时才执行工厂函数”，但如果工厂函数抛异常，这个异常会被缓存——后续每次读 Value 都直接 rethrow，不是重新尝试初始化。很多人误以为会重试，结果日志里反复看到同一个 NullReferenceException 却查不到源头。
实操建议：
- 显式传入 LazyThreadSafetyMode.ExecutionAndPublication（默认值，但写出来更清晰）
- 工厂函数内必须包住所有可能异常，或至少 log 出错上下文
- 检查是否真需要延迟加载：如果构造开销不大，直接用静态只读字段反而更透明
- 示例：
private static readonly Lazy<myservice> _instance = new Lazy<myservice>(() => { try { return new MyService(); } catch (Exception ex) { Log.Error(ex); throw; } }, LazyThreadSafetyMode.ExecutionAndPublication);</myservice></myservice>
Singleton 实例被 GC 回收？那是你用了错误的 Lazy 构造方式
如果用的是 new Lazy<t>(Func<t>)</t></t> 无参构造，实例生命周期由 GC 管理，一旦没有强引用指向 Lazy<t></t> 对象本身，整个延迟初始化机制就失效了——下次再 new 一个 Lazy<t></t>，又会重新创建实例。这不是单例，是“伪单例”。
实操建议：
- Lazy<t></t> 实例必须是静态字段，且不能被意外覆盖或置为 null
- 不要把它塞进局部变量、方法参数或临时容器里
- 避免在 DI 容器中注册 Lazy<t></t> 类型本身（除非你明确知道容器如何持有它）
- 检查反编译后的 IL：静态字段应有 .field private static initonly 修饰
Async 初始化怎么办：Lazy 不支持 async/await
Lazy<t></t> 的工厂委托不接受 async，强行用 GetAwaiter().GetResult() 会阻塞线程，尤其在 ASP.NET Core 同步上下文受限时容易死锁。这不是设计缺陷，而是 Lazy 语义上就是同步初始化。
实操建议：
- 真需要异步初始化，改用 AsyncLazy<t></t>（第三方库如 Nito.AsyncEx 提供）
- 或自己封装：用 Task<t></t> 静态字段 + Interlocked.CompareExchange 控制首次启动
- 别把数据库连接、HTTP 客户端等本该由 DI 管理的资源硬塞进单例——它们天然适合作用域生命周期
最常被忽略的一点：单例是否真需要“全局唯一”？很多场景下只是“当前请求内唯一”或“当前配置下唯一”，这时候用 IServiceProvider 的 scoped 生命周期比手写单例更安全、更易测、更少线程陷阱。
