.NET 依赖注入惯例：生命周期、作用域与“被困依赖”陷阱

是什么

《.NET 文档》描述了一个内置容器：服务在启动时被添加到 IServiceCollection 中（通过 AddTransient、AddScoped、AddSingleton，或它们的键控（keyed）变体），BuildServiceProvider 或通用主机（generic host）会创建出 IServiceProvider，使用方则通过公共构造函数获得依赖。transient 服务在每次被请求时都会重新创建；scoped 服务在每个作用域内只创建一次，在 ASP.NET Core 中这个作用域就是一次请求；singleton 服务在容器的整个生命周期内只创建一次。容器会释放自己创建的对象：transient 和 scoped 实例在其作用域结束时释放，singleton 在应用关闭时释放。当一个类型有多个构造函数时，会选用可由 DI 解析的参数最多的那一个，出现歧义时则会抛出异常。

为什么重要

来自 Spring（默认单例）或不带容器的框架的工程师，往往习惯把所有东西都注册成 singleton，或者手动解析服务。官方指南把由此产生的 bug 称为“被困依赖”（captive dependency）：一个生命周期更长的服务持有了一个生命周期更短的服务，于是被 singleton 捕获的“每请求一份”的 DbContext，就会被所有请求悄悄共享。生命周期文档明确指出，scoped 服务不应通过构造函数注入、也不应通过 IServiceProvider 从 singleton 中解析；官方给出的修复办法是用 IServiceScopeFactory 显式创建一个作用域。

如何应用

• 默认情况下，无状态服务用 transient，按请求存在的状态（DbContext、工作单元）用 scoped，只有共享的、线程安全的、创建代价高的状态才用 singleton；官方指南要求 singleton 必须线程安全，并提醒要注意耦合和内存问题。
• 让构造函数依赖接口，并且构造函数中除了赋值之外不做其他工作。
• 永远不要在注入的服务上调用 Dispose，也不要把可能从根容器（root provider）解析出来的 IDisposable 类型注册成 transient；官方指南指出，这类实例会一直被持有，直到容器被释放为止。
• 配置服务时不要调用 BuildServiceProvider，也不要把 GetService 当作服务定位器使用；这两者都被列为反模式。
• 保持作用域校验开启：开发环境主机会检查 scoped 服务既没有从根容器解析，也没有被注入到 singleton 中；在其他场合，给 BuildServiceProvider 传入 validateScopes: true 可以起到同样的作用。
• 在托管服务（hosted service）或后台服务中，注入 IServiceScopeFactory，并为每个工作单元创建一个作用域。

常见陷阱

静态访问容器（比如捕获一份 ApplicationServices）被列为应当避免的做法：官方指南指出，一旦和静态对象访问混用，DI 的好处也就没有了。把配置或用户数据存在容器里，而不是使用 options 模式。键控服务需要在参数上标注 [FromKeyedServices("key")]。把同一个服务注册两次是合法的，但很容易被忽略。