.NET Core 8后台服务中Scoped服务与仓储的依赖注入范围问题

你不需要在IMailRepository里创建作用域，这完全没必要，问题出在服务生命周期配置或者依赖注入方式上，以下是具体解决步骤：

1. 检查服务注册的生命周期 #

确保IMailService和IMailRepository都注册为Scoped（或者IMailRepository为Transient，Scoped服务可以安全依赖这两种生命周期的服务）。在Program.cs中的注册代码应该类似：

// Scoped生命周期：每个作用域内实例唯一
builder.Services.AddScoped<IMailService, MailService>();
builder.Services.AddScoped<IMailRepository, MailRepository>();

如果IMailRepository被注册为Singleton，会导致Scoped的IMailService无法正确依赖它（Singleton属于根作用域，无法访问子作用域的Scoped服务），这时候必须调整IMailRepository的生命周期为Scoped/Transient。

2. 确保通过构造注入传递依赖 #

IMailService的实现类必须通过构造函数注入获取IMailRepository，而不是手动实例化或者从非当前作用域的ServiceProvider获取。示例：

public class MailService : IMailService
{
    private readonly IMailRepository _mailRepository;

    // 构造注入：自动从当前作用域解析IMailRepository
    public MailService(IMailRepository mailRepository)
    {
        _mailRepository = mailRepository;
    }

    public async Task SendSomeMail()
    {
        // 直接使用_mailRepository，它属于当前作用域
        var mailData = await _mailRepository.GetMailDataAsync();
        // ... 发送邮件逻辑
    }
}

如果IMailService里是手动创建IMailRepository或者用了根容器的ServiceProvider，就会导致它不在你后台服务创建的作用域内，从而报错。

3. 后台服务的作用域逻辑保持现状 #

你当前在后台服务中创建作用域的代码是正确的：

using (var scope = _serviceProvider.CreateScope())
{
    var scopedService = scope.ServiceProvider.GetRequiredService<IMailService>();
    await SendMail(scopedService, stoppingToken);
    await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
}

这个作用域会覆盖所有从它解析出的Scoped服务的整个依赖链——只要依赖注入配置正确，IMailService依赖的IMailRepository会自动属于同一个作用域，不需要额外操作。

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