.NET依赖注入AddTransient调用是否存在数量上限？遇栈溢出异常咨询

First off, let’s clear up a key point: there’s no official limit on the number of AddTransient registrations in .NET Core’s built-in DI container (Microsoft.Extensions.DependencyInjection). That 22/23 threshold isn’t a hard cap—it’s a red flag pointing to a hidden issue in your dependency chain or registration logic, not a limitation of the framework.

Here’s how to diagnose and fix this:

Common Root Causes #

• Hidden Circular Dependency
  Even if your 23rd class’s constructor looks identical to the others, it might be part of an indirect circular dependency that only triggers when you add that 23rd registration. For example:
  Service23 → ServiceX → ServiceY → Service23
  When the container tries to resolve Service23, it gets stuck in an infinite recursive loop, eventually blowing the stack. The 22-registration count might just be the point where this loop crosses the stack’s depth limit.

• Accidental Recursion in Registration Logic
  Double-check if your registration code has any unintended recursion—like a loop that generates registrations until it hits 23, or a helper method that accidentally re-registers services multiple times. This could pile up calls and trigger a stack overflow when you add the 23rd explicit registration.

• Unusually Deep Dependency Chain
  While rare, if each of your 23 services has a long chain of dependencies, adding the 23rd might push the total stack depth needed for resolution over the .NET runtime’s default stack size. This is less likely than a circular dependency, but worth checking.

Step-by-Step Fixes #

1. Force Dependency Resolution to Expose the Loop
   At the end of your ConfigureServices method, try manually resolving the 23rd service with a built service provider:

   var sp = services.BuildServiceProvider();
   var problematicService = sp.GetService<Your23rdServiceType>();
   

   If this throws a StackOverflowException immediately, you’ve confirmed the issue is in the dependency chain for that service.

2. Map Out the Dependency Tree
   List out every dependency of your 23rd service, then each dependency of those services, and so on. Look for any closed loop—this is almost always the culprit. A simple text document or whiteboard sketch can help visualize this chain quickly.

3. Simplify Registration with Bulk Scanning
   Instead of writing 23+ manual AddTransient calls, use bulk registration to reduce human error and clean up your code. For example, using the Scan extension (from the Microsoft.Extensions.DependencyInjection.Extensions package):

   services.Scan(scan => scan
       .FromAssemblyOf<YourBaseServiceType>()
       .AddClasses()
       .AsImplementedInterfaces()
       .WithTransientLifetime());
   

   This automatically registers all matching services in your assembly, eliminating the risk of typos or accidental duplicates.

4. Enable DI Container Validation
   When building your service provider, enable validation to catch common DI issues early:

   var sp = services.BuildServiceProvider(new ServiceProviderOptions { 
       ValidateScopes = true,
       ValidateOnBuild = true
   });
   

   This will throw descriptive errors at startup if there are invalid dependencies or circular references, saving you from debugging runtime crashes.

5. Break the Circular Dependency (If Found)
   If you spot a loop, fix it by:

   • Refactoring the dependency chain to remove the loop (preferred, as it improves code design).
   • Using lazy resolution with Lazy<T> or Func<T> to delay resolving the dependent service.
   • Using property injection as a last resort (note: this violates the Dependency Inversion Principle and should be avoided if possible).

Final Notes #

Don’t fixate on the 22/23 number—it’s just the trigger, not the cause. The real issue is almost always a hidden circular dependency or flawed registration logic. By systematically checking your dependency chains and simplifying your DI setup, you’ll resolve the StackOverflowException without hitting any imaginary limits.

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