.NET Core内置DI的AddSingleton()是否等价于单例设计模式实现？

明确结论：两者并不等价，在实例管控、依赖处理、可维护性等多个维度存在显著差异，具体区别如下：

1. 实例创建时机 #

• 手动单例：实例创建时机由开发者写的逻辑控制，要么是类加载时直接初始化（饿汉式），要么是第一次调用获取实例方法时创建（懒汉式）。
• AddSingleton：默认是延迟初始化（除非你主动传入已实例化的对象），只有当首次从DI容器中解析该服务时，才会创建实例，时机由容器管控。

2. 线程安全保障 #

• 手动单例：线程安全需要开发者自己实现，比如加双重锁，一旦逻辑写漏就可能出现多实例问题。
• AddSingleton：DI容器内置了线程安全的实例创建逻辑，无需开发者额外处理，确保整个应用生命周期内只会生成一个实例。

3. 依赖注入能力 #

• 手动单例：如果单例类本身有依赖，必须手动创建并注入依赖对象，无法借助DI容器的自动解析能力，容易出现硬编码依赖的情况。
• AddSingleton：只要单例类的依赖已经在容器中注册，容器会自动解析并注入这些依赖，大幅简化依赖管理逻辑。

4. 可测试性 #

• 手动单例：由于实例是全局唯一且硬编码实现，单元测试时很难替换为模拟对象，测试灵活性极低。
• AddSingleton：测试时只需修改容器的注册配置，就能轻松将真实实现替换为Mock对象，提升测试效率。

5. 扩展性与维护性 #

• 手动单例：如果后续需要修改实例的生命周期（比如从单例改为作用域实例），必须修改类本身的代码，违反开闭原则。
• AddSingleton：只需调整容器注册代码（比如换成AddScoped或AddTransient），无需改动服务类本身，更符合面向对象设计原则。

代码示例对比 #

手动单例实现

public class MyDependency : IMyDependency
{
    private static MyDependency _instance;
    private static readonly object _lockObj = new object();

    private MyDependency() {}

    public static MyDependency GetInstance()
    {
        if (_instance == null)
        {
            lock (_lockObj)
            {
                _instance ??= new MyDependency();
            }
        }
        return _instance;
    }
}

DI容器注册单例

services.AddSingleton<IMyDependency, MyDependency>();

总结来说，AddSingleton是由DI容器托管的单例，它解决了手动单例模式的诸多痛点，是更符合.NET Core生态的单例实现方式，和手动编写的单例模式并非等价概念。

内容的提问来源于stack exchange，提问作者Sharad