泛型单例必须用Lazy实现，因C#禁止泛型静态字段直接初始化，Lazy延迟实例化并保障线程安全；每个闭合类型（如Singleton、Singleton）独立成单例，互不影响。
泛型单例不能靠 static class 或裸 static T _instance = new T() 实现——前者语法报错，后者编译不通过，且多线程下必然崩。
为什么泛型单例必须用 Lazy<t></t>
因为 C# 不允许泛型类型参数参与静态字段的直接初始化：private static T _instance = new T() 会触发 CS0718（泛型静态字段非法）或 CS0308（缺少 new() 约束）。而 Lazy<t></t> 把实例化逻辑推迟到 .Value 首次访问时，并由其内部保证线程安全与内存可见性，绕过了所有语言限制。
-
Lazy<t></t>的构造函数接受一个Func<t></t>，你控制创建时机和方式，比如加载配置、连接数据库 - 必须加
where T : class, new()：class排除值类型（避免装箱/默认值陷阱），new()是new T()的硬性前提 -
LazyThreadSafetyMode.ExecutionAndPublication是默认模式，不用显式写；但若手动指定，别误用None
Singleton<t>.Instance</t> 每个闭合类型都是独立单例
这不是“一个单例支持多种类型”，而是“每种具体类型各有一个单例”——Singleton<string>.Instance</string> 和 Singleton<int>.Instance</int> 完全无关，地址不同、生命周期分离、互不影响。这点常被误认为“复用失败”，其实是设计本意。
- 如果你需要统一管理多个类型的实例（比如都走同一套缓存策略），别硬套泛型单例，改用非泛型容器 +
Dictionary<type object></type>+ 锁 - DI 容器注册时也得按闭合类型处理：
services.AddSingleton<irepository>, UserRepository>()</irepository>，不是注册开放泛型IRepository就完事 - 单元测试中，
Singleton<mockservice>.Instance</mockservice>和Singleton<realservice>.Instance</realservice>不会互相污染，这是优势
手写 DCL 或 lock 在泛型类里几乎没意义
有人试图在泛型类里照搬非泛型 DCL 写法：private static volatile T _instance + lock —— 这行不通。泛型静态字段本身就不被允许，volatile 修饰符对泛型参数无效，编译直接失败。
- 不要尝试用
typeof(T)做锁对象：锁粒度失控，容易死锁，且无法保证跨 AppDomain 或热重载行为 - 别把
Lazy<t></t>当成“可选优化”：它是目前唯一能在泛型上下文中兼顾类型安全、线程安全、懒加载的合法路径 - 如果初始化开销极小、且确定启动即用，饿汉式（静态构造函数内 new）更轻量——但泛型类没有静态构造函数能绑定到
T，所以这条路对泛型单例根本走不通
生产环境优先走 DI 容器注册
手写 Singleton<t></t> 很容易在生命周期管理上翻车：比如依赖注入链中某环节需要 IDisposable，手动单例不会自动调用 Dispose；又或者测试时无法替换 mock 实例。
- ASP.NET Core 中注册开放泛型单例要两步：
services.AddSingleton(typeof(IHandler), typeof(Handler))，然后才能解析scope.GetRequiredService<ihandler>>()</ihandler> - 注册顺序很重要：开放泛型映射必须在任何闭合泛型解析之前完成，否则抛
InvalidOperationException - DI 容器自动处理线程安全、作用域传播、释放链，比手写
Lazy<t></t>更健壮，尤其当T构造函数依赖其他服务时
真正容易被忽略的是：泛型单例的“单例性”只在闭合类型维度成立，它不提供跨类型协调能力；而 DI 容器里的泛型注册，本质是运行时生成的闭合类型工厂，不是编译期泛型类的简单复用——这两者语义不同，选错会导致后期维护成本陡增。
