依赖注入的三种生命周期为Singleton、Scoped和Transient：Singleton全程单例；Scoped在每个作用域内单例，需配合IServiceScope使用；Transient每次解析新建实例。 Scoped服务不可在根容器直接解析，须通过CreateScope()创建作用域并及时释放。
在C#的.NET Core及后续版本中，依赖注入（DI）的生命周期管理是核心机制之一，它决定了服务实例何时创建、复用和释放。理解 作用域（Scope） 是掌握DI行为的关键——不是所有服务都该“单例”，也不是所有都该“每次新建”，而作用域正是控制“谁在什么时候能拿到同一个实例”的边界。
三种基础生命周期：Singleton、Scoped、Transient
它们不是抽象概念，而是注册服务时明确指定的行为策略：
- Singleton：整个应用生命周期内只创建一次实例，所有请求共享同一对象。适合无状态工具类、配置读取器、连接池管理器等。
- Scoped：每个 作用域（Scope）内 创建一次，同个Scope内多次解析返回同一实例；不同Scope间互不干扰。这是Web请求中最常用的模式（如一个HTTP请求就是一个Scope）。
- Transient：每次请求都新建实例，无共享、无状态依赖。适合轻量、无副作用的临时对象，比如DTO映射器、简单计算服务。
Scoped生命周期必须配合Scope使用，否则退化为Transient
Scoped服务只有在显式或隐式创建的 IServiceScope 内才能正确复用。在ASP.NET Core中，框架自动为每个HTTP请求创建一个Scope，所以Controller里注入的Scoped服务天然按请求隔离。
但如果你在后台任务、静态方法或HostedService中直接从 IServiceProvider（根容器）解析Scoped服务，会抛出异常或行为异常——因为根容器没有Scope上下文。
正确做法是手动创建Scope：
using var scope = serviceProvider.CreateScope(); var myService = scope.ServiceProvider.GetRequiredService<IMyScopedService>(); // 使用myService...
注意：务必 using 或 Dispose() Scope，否则可能引发内存泄漏或资源未释放。
Scope嵌套与服务解析链路
Scope支持嵌套。子Scope可以解析自己创建的服务，也能访问父Scope的Singleton和Scoped服务（但不会覆盖父级实例）。例如：
- 根容器注册了
ILogger<a></a>为Singleton → 所有Scope共用一个日志器实例。 - 主HTTP请求Scope注册了
IDbContext为Scoped → 同一请求中Controller、Service、Repository拿到的是同一个DbContext。 - 你在Controller里手动
CreateScope()→ 新Scope中的IDbContext就是另一个新实例，与外层请求无关。
这种嵌套让单元测试、事务隔离、多租户上下文等场景更可控。
常见陷阱与建议
- 不要在Singleton服务中持有Scoped服务的引用：会导致Scoped实例被长期驻留，破坏生命周期，可能引发并发问题或数据库上下文异常。
- 避免在构造函数中跨Scope传递服务：比如把Scoped服务传给Singleton类的构造函数——注册时就会报错。
-
需要“请求内单例”？优先用Scoped，而不是自己用
AsyncLocal<t></t>或静态字典模拟——DI容器已为你做好了。 -
自定义Scope边界：可通过
IServiceScopeFactory在任意位置创建Scope，比如一个消息处理单元、一次定时任务执行。
基本上就这些。作用域不是魔法，它是DI容器帮你画的一道“可见性+生存期”的线——划清了对象该活多久、被谁看见。用对了，代码更健壮；用错了，Bug往往静默又难查。
