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