scoped 服务必须绑定到明确的 iservicescope 实例，根容器无作用域上下文，直接解析会抛出 invalidoperationexception 或导致静默数据污染；正确做法是手动调用 createscope() 并确保及时释放。
直接说结论：Scoped 不是“每个请求一个实例”的简单等价，而是“每个 IServiceScope 一个实例”；用错地方（比如在根容器直接解析）会导致运行时异常或静默数据污染，比 Transient 错配更危险。
为什么 Scoped 服务在 HostedService 或静态方法里解析会报错？
因为 IServiceProvider 根容器没有作用域上下文。Scoped 服务必须绑定到一个明确的 IServiceScope 实例上，否则 DI 容器无法确定“这个 Scoped 实例该属于谁”。
常见错误现象：
- 调用
serviceProvider.GetService<ishoppingcartservice>()</ishoppingcartservice>返回 null（.NET 6+ 默认行为） - 或抛出
InvalidOperationException: Cannot resolve scoped service 'IShoppingCartService' from root provider - 更隐蔽的是：某些版本下“看似成功”，但实际退化为 Transient 行为，引发状态不一致
正确做法是手动创建作用域：
using var scope = serviceProvider.CreateScope(); var cartService = scope.ServiceProvider.GetRequiredService<ishoppingcartservice>();</ishoppingcartservice>
注意：CreateScope() 返回的 IServiceScope 必须被 using 或显式 Dispose()，否则可能造成内存泄漏或 DbContext 未释放。
Transient 和 Scoped 在 Web 请求中到底差在哪？
差异不在“创建时机”，而在“复用边界”。同一个 HTTP 请求中：
-
AddTransient：Controller、Middleware、Filter 里每次GetService都拿到新实例 -
AddScoped：只要在同一个请求的 Scope 内（默认自动提供），所有位置注入的都是同一实例
典型陷阱场景：
你在 Controller 构造函数注入 IDbContext（Scoped），又在 Action 里手动从 HttpContext.RequestServices 解析一次 —— 这俩是同一个对象；但若从 Program.Services（即根容器）解析，就完全不是一回事。
性能影响：Scoped 初始化开销只发生一次/请求；Transient 即使是轻量类，频繁 new + GC 也有可观成本，尤其高并发时。
什么时候该选 Scoped 而不是 Transient？
核心判断标准不是“要不要共享”，而是“共享是否安全且必要”。
- 需要跨多个组件维持临时状态：如购物车、表单验证上下文、请求级缓存
- 封装了非线程安全资源：如
DbContext必须 Scoped，否则并发写入会崩溃 - 初始化代价较高，但又不能全局共享：如一次请求内需多次访问的远程配置快照
反例：DTO 映射器、字符串格式化工具、纯计算函数 —— 这些用 Transient 更干净，无状态、无副作用、构造快。
容易被忽略的点：Scoped 服务内部如果持有对 Singleton 服务的引用，没问题；但如果反过来，Singleton 持有 Scoped 服务引用（比如通过构造函数注入），编译能过，运行必炸 —— 因为生命周期容器不允许“长生命周期依赖短生命周期”。
