Singleton 实例在容器生命周期内只创建一次，首次请求时生成并全程复用；Scoped 按作用域（如每个 HTTP 请求）创建独立实例；Transient 每次请求都新建对象。
Singleton 实例在容器生命周期内只创建一次
当你注册为 Singleton，DI 容器会在第一次请求该服务时创建实例，并一直复用它——哪怕跨多个 HTTP 请求、跨线程、跨作用域。这意味着所有地方拿到的都是同一个对象引用。
适合无状态工具类（如日志记录器 ILogger）、配置读取器、或需要全局共享状态的组件（比如缓存管理器）。但要注意：如果它内部持有可变状态且没做线程同步，多线程下容易出错。
- 注册方式：
services.AddSingleton() - 不推荐用于依赖
Scoped服务（如 EF Core 的DbContext），否则会引发“Cannot resolve scoped service from root provider”错误 - 构造函数注入的
Scoped或Transient服务，在Singleton中只会被解析一次（即“快照式绑定”）
Scoped 实例按作用域边界创建，常见于 Web 请求生命周期
ASP.NET Core 默认每个 HTTP 请求就是一个 Scoped 作用域。同一请求内多次 GetRequiredService 拿到的是同一个实例；不同请求之间则各自独立。
这是 EF Core 的 DbContext 默认注册方式的原因：保证一个请求内数据库操作共享上下文，又避免跨请求状态污染。
- 注册方式：
services.AddScoped() - 在非托管作用域（如后台任务、
Task.Run）中直接从根容器解析Scoped服务会失败，报错：Cannot resolve scoped service from root provider - 若需在后台任务中使用，必须手动创建作用域：
using var scope = app.Services.CreateScope(); scope.ServiceProvider.GetRequiredService()
Transient 每次请求都新建实例，无共享状态
Transient 是最轻量的生命周期，每次调用 GetRequiredService 或构造函数注入时都会 new 一个新对象。没有复用，也没有隐式状态传递风险。
适合无状态、开销小、或需要隔离数据的类型，比如 DTO 映射器、计算工具类、或单元测试中的模拟对象。
- 注册方式：
services.AddTransient() - 性能上比
Scoped和Singleton略低（对象分配 + GC 压力），但多数场景可忽略 - 可以安全注入到任何生命周期的服务中（包括
Singleton），但要注意：如果Singleton持有Transient实例，那个实例就变成“伪单例”了——它不会更新，也不会重新创建
DI 容器解析失败时的典型错误信息和排查点
最常见的报错是 InvalidOperationException: Cannot resolve scoped service 'MyApp.IDbContext' from root provider.，本质是试图在没有作用域的上下文中（如静态方法、HostedService 构造函数）直接解析 Scoped 服务。
- 检查调用栈：是否在
IHostedService.StartAsync、Program.cs顶层代码、或静态工厂方法里用了app.Services.GetService() - 确认服务注册顺序：后注册的覆盖先注册的，但生命周期不能降级（比如先
AddScoped后AddSingleton会生效后者） - 调试技巧：在服务构造函数里加日志或断点，观察调用次数和线程 ID，能快速识别生命周期是否符合预期
实际项目里最容易被忽略的，是 Singleton 类型中悄悄持有了 Scoped 服务的引用——它不会编译报错，但运行时可能因上下文已释放而抛出 ObjectDisposedException。
