如何在.NET Worker Service的深层类结构中实现构造器注入？

1. 是否可以跳过类层次逐层传参，直接在深层类完成服务注入？ #

完全可以。
你现在遇到的“只有Worker层能正常注入”的错觉，本质是代码里那行new TestClassServ(TestServ)——DI容器的自动注入能力，只对由容器负责创建的实例生效，只要实例是手动写代码new出来的，容器完全感知不到它的存在，自然不会帮你填充它的构造依赖，这和类的嵌套深度没有任何关系。
这和ASP.NET Core MVC的逻辑完全一致：MVC框架不会让你手动new控制器，所以控制器的所有构造依赖都会被容器自动解析；如果你在MVC的Action里手动new一个下游类，这个类的依赖同样需要你手动传，和是不是MVC项目没有关系。

2. 具体实现步骤 #

基础固定实例场景 #

如果类是固定依赖关系、不需要运行时动态创建多实例，按三步操作就能实现全程自动注入，体验和MVC控制器完全一致：

• 第一步：把所有需要使用DI的类，全部注册到服务容器
  代码里的TestClassServ不需要手动实例化，直接在Program.cs的服务配置段注册即可，哪怕是具体类（不用抽象接口）也可以：

  services.AddTransient<TestClassServ>();
  

  容器在解析TestClassServ的时候，会自动识别它构造函数里需要的ITestService依赖，从已注册的服务里找到对应实现自动传入，不需要你手动衔接参数。
• 第二步：在Worker的构造函数里直接注入需要的下游类，不要手动new
  修改后的Worker代码会完全移除手动实例化的逻辑：

  public class Worker : BackgroundService
  {
      private readonly ILogger<Worker> _logger;
      private readonly TestClassServ _testClassServ;
  
      // 直接把下游类作为构造参数，容器自动完成所有依赖解析
      public Worker(ILogger<Worker> logger, TestClassServ testClassServ)
      {
          _logger = logger;
          _testClassServ = testClassServ;
      }
  
      protected override async Task ExecuteAsync(CancellationToken stoppingToken)
      {
          while (!stoppingToken.IsCancellationRequested)
          {
              _logger.LogInformation("TestService: " + _testClassServ.GetData());
              await Task.Delay(1000, stoppingToken);
          }
      }
  }
  

• 针对你遇到的配置、日志注入场景：只要类是从容器解析出来的，直接在构造函数里加IConfiguration、ILogger<T>参数就能自动拿到对应实例，完全不需要逐层传递。

运行时动态创建实例场景 #

如果需要在循环/任务执行过程中动态创建多个独立的类实例（比如每个处理任务需要独立的作用域服务），不能直接在构造函数注入时，使用官方推荐的IServiceScopeFactory动态创建实例，不要手动new：

public class Worker : BackgroundService
{
    private readonly ILogger<Worker> _logger;
    private readonly IServiceScopeFactory _scopeFactory;

    public Worker(ILogger<Worker> logger, IServiceScopeFactory scopeFactory)
    {
        _logger = logger;
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            // 每次创建独立作用域，从容器中获取需要的类实例，所有依赖自动解析
            using var scope = _scopeFactory.CreateScope();
            var testClassServ = scope.ServiceProvider.GetRequiredService<TestClassServ>();
            _logger.LogInformation("TestService: " + testClassServ.GetData());
            await Task.Delay(1000, stoppingToken);
        }
    }
}

注意：不要直接把根容器IServiceProvider注入进来获取实例，会引发服务作用域泄漏，使用IServiceScopeFactory是官方明确推荐的动态实例获取方式。

3. 这个问题是否源于架构设计不合理？ #

不是嵌套类结构的问题，本质是实例化方式误用打断了DI容器的解析链。

• 正常的分层、类嵌套架构本身没有任何问题：只要每一层的类实例都是从DI容器中创建的，依赖会顺着构造函数一路自动解析到最底层，完全不需要逐层手动传参。你现在遇到的“需要逐层传参”，是因为手动new了本该由容器管理的类，相当于把原本自动贯通的解析链打断了。
• 真正属于架构不合理的场景是：为了传递少数几个服务，把跨多层的依赖全部堆到顶层类的构造函数里，接十几个服务参数，再一层层手动向下传递。这种情况的优化方向也不是“强行在深层类里做注入”，而是按职责拆分，把拥有共同依赖的类聚合成独立的服务单元，注册到容器里由容器统一解析即可。

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