C#中构造函数注入服务与CreateScope()的差异及存在意义疑问

.NET的依赖注入体系默认有三种服务生命周期，你有Java开发经验可以对应Spring的同类作用域概念理解：

• Singleton：全局唯一实例，生命周期与应用进程完全一致
• Scoped：单个作用域内唯一，ASP.NET Core默认每个HTTP请求对应一个独立Scoped作用域
• Transient：每次请求服务时都创建全新实例

你提到的写法是.NET DI体系下的常规操作，核心是为了解决跨生命周期服务访问、服务上下文隔离的需求，不用直接注入目标服务的常见原因如下： #

1. 父服务为Singleton生命周期，无法直接注入Scoped服务 #

如果当前类本身被注册为Singleton（比如后台定时任务、IHostedService实现、全局公共工具类等），直接在构造函数注入Scoped生命周期的服务会触发两种异常情况：

• 严格的DI容器校验会在应用启动时直接抛出生命周期不匹配的错误
• 就算关闭校验允许注入，你拿到的Scoped服务实例会跟随Singleton父服务一直存活，完全失去Scoped的隔离特性，比如共用DbContext导致并发写入冲突、数据脏读等问题。

IServiceScopeFactory本身是Singleton生命周期的，可以安全注入到任何生命周期的服务中。通过它创建新作用域后再解析服务，就能拿到符合生命周期定义的正常实例，配合using语法，作用域销毁时内部解析的所有Scoped/Transient服务也会被同步释放，不会造成内存泄漏。
你看到的就是这类场景的标准写法：

// 构造函数注入Singleton的IServiceScopeFactory
public MyService(IServiceScopeFactory scopeFactory,......)
{
    this.scopeFactory = scopeFactory;
}

// 方法内显式创建作用域解析服务
using var scope = scopeFactory.CreateScope();
var mediator = scope.ServiceProvider.GetRequiredService<IMediator>();
await mediator.Send(....);

2. 需要独立的服务隔离上下文 #

哪怕当前类本身是Scoped生命周期（比如ASP.NET Core的Controller），部分场景也需要手动创建独立作用域：
比如你要批量处理10个互不相干的业务任务，每个任务需要独立的DbContext、独立的事务上下文，这时候给每个任务单独创建一个作用域，每个作用域内解析的服务互不干扰，某个任务执行失败也不会影响其他任务的上下文，也不会污染当前请求的全局Scoped上下文。 #

3. 手动控制服务的释放时机 #

部分场景下目标服务的使用周期远短于当前父类的生命周期，比如你在一个运行时长长达几小时的后台任务里，只需要在某几行逻辑中用到占用大量资源的服务，显式创建作用域配合using语法，可以在逻辑执行完后立刻释放相关服务资源，不用等到父类被销毁才释放。

至于你提到的为什么不直接注入IMediator，大概率是两个原因：要么当前类是Singleton注册的，无法直接注入依赖了Scoped服务的IMediator；要么每次调用mediator.Send的逻辑需要独立的服务上下文，避免和当前作用域的其他逻辑产生上下文干扰。

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