RegisterScoped 并非 .NET 原生方法，而是第三方或自定义封装；应统一使用 AddScoped，中间件构造函数不可注入 Scoped 服务，DbContext 应通过 AddDbContext 注册，Scoped 服务禁止持有 HttpContext。
RegisterScoped 和 AddScoped 有什么区别
没有区别。AddScoped 是 IServiceCollection 接口上的扩展方法，而 RegisterScoped 并不存在于 .NET 原生 API 中——它常见于某些第三方容器（比如 Autofac）或自定义封装里。如果你在项目里看到 RegisterScoped，大概率是团队自己写的扩展方法，不是标准写法。
实操建议：
- 统一用
AddScoped，避免混淆；如果用了自定义方法，务必在项目文档里说明其内部是否真按 scope 行为实现（比如是否真的绑定到IServiceProvider的当前 scope） - 检查是否误把
AddTransient或AddSingleton写成RegisterScoped—— 编译不报错但行为完全不对 - .NET 6+ 中所有内置 DI 容器（包括默认的 Microsoft.Extensions.DependencyInjection）只认
AddScoped
Scoped 服务在中间件里调用会出什么问题
在中间件中直接通过构造函数注入 Scoped 服务，会导致运行时异常：System.InvalidOperationException: Cannot resolve scoped service 'X' from root provider。
原因很简单：中间件实例由根容器创建并长期驻留，而 Scoped 服务必须绑定到一个请求 scope（即 HttpContext.RequestServices），不能从根 IServiceProvider 解析。
实操建议：
- 中间件构造函数里**不要注入任何
Scoped服务**，只允许Singleton或无状态对象 - 需要访问
Scoped服务时，在Invoke或InvokeAsync方法里通过context.RequestServices.GetService获取() - 更安全的做法是使用
context.RequestServices.GetRequiredService，避免返回 null 导致后续 NRE()
Entity Framework Core 的 DbContext 默认就是 Scoped，还能手动 AddScoped 吗
能加，但没必要，而且容易引发重复注册和生命周期混乱。
DbContext 类型本身不带生命周期标记，EF Core 的 AddDbContext 扩展方法内部已经调用了 AddScoped（.NET 5+ 默认行为），所以显式再写一遍 services.AddScoped 会造成两次注册，后者会覆盖前者——但 EF Core 的注册还附带了额外配置（如连接字符串、options builder），手动注册会丢失这些。
实操建议：
- 始终用
AddDbContext注册，不要手动AddScoped同一类型 - 如果要换生命周期（比如测试时想用 Transient），应改用
AddDbContextFactory+ 自定义工厂逻辑，而不是硬切生命周期 - 注意：多个
AddDbContext调用注册不同DbContext子类时互不影响，但同一类型重复注册会触发警告（.NET 6+ 日志里可见）
Scoped 服务里持有 HttpContext 会有什么隐患
会引发内存泄漏和并发错误。因为 HttpContext 是请求级对象，生命周期严格绑定到单次 HTTP 请求；而 Scoped 服务虽然也“按请求”，但它可能被缓存、复用，甚至跨多个异步操作延续——一旦它持有了 HttpContext 引用，就等于把整个请求上下文钉在内存里，直到该 scope 结束（通常是请求结束），但若 scope 提前释放失败或被意外延长，HttpContext 就无法释放。
实操建议：
- Scoped 服务中**禁止保存
HttpContext字段或属性**；如需访问用户身份、请求头等，应在方法调用时传入HttpContext或提取所需字段（如ClaimsPrincipal、HttpRequest） - 如果必须关联上下文，考虑用
IHttpContextAccessor，但它本身是 Singleton，需确保只在需要时获取、不长期持有 - 特别警惕异步场景：await 后续操作中若仍引用已失效的
HttpContext，会抛ObjectDisposedException
最常被忽略的一点是：scoped 不等于“每次请求新建一次实例”——它依赖 scope 的正确开启与释放。中间件没写对、后台任务没手动创建 scope、或者用了 Task.Run 脱离上下文，都会让 scoped 服务退化成 singleton 或直接崩溃。别只看注册方式，得盯住 scope 实际存在的时间窗口。
