使用IServiceScopeFactory创建多线程Scoped DB Context的弊端有哪些？

• 额外的性能与内存开销：每次通过IServiceScopeFactory创建新的作用域时，都会实例化全新的DbContext对象，同时会初始化该作用域下所有关联的依赖服务。DbContext本身的初始化（加载模型元数据、配置变更追踪器、建立数据库连接会话等）存在固定成本，高并发场景下频繁创建、销毁作用域会带来明显的额外GC压力，高频调用场景下性能损耗会被放大。
• 事务处理复杂度大幅提升：不同作用域下的DbContext是完全独立的实例，默认不共享数据库连接和事务上下文。如果多个并发数据库操作需要在同一个事务内完成提交或回滚，跨作用域的事务处理要么需要引入分布式事务，要么需要手动封装共享连接逻辑，不仅提升代码复杂度，还会大幅提高事务死锁、连接泄漏的概率。
• 实体追踪状态断裂：从构造函数注入的根作用域DbContext中查询到的带变更追踪的实体，无法直接传入子作用域的DbContext执行更新、删除操作。两个DbContext的追踪栈完全隔离，直接传递实体会抛出「实体已被其他上下文追踪」的异常，必须额外执行实体detach、重新attach、字段手动映射等操作，不仅增加代码冗余量，还容易出现实体状态同步错误。
• 生命周期管理风险：如果使用时遗漏了using语句包裹创建的作用域，会导致DbContext无法被及时释放，出现数据库连接泄漏的问题；另外如果在子作用域中错误地持有了长生命周期服务（如单例服务）的引用，还会引发非预期的内存泄漏问题。
• 代码维护成本上升：项目中同时存在两种DbContext获取方式：构造函数直接注入、IServiceScopeFactory动态创建，开发人员很容易混淆两种方式的使用场景，比如误将根作用域的DbContext传入异步线程执行引发并发错误，或者在非并发场景冗余创建作用域造成不必要的性能损耗，大幅提升代码维护成本和线上故障概率。

内容的提问来源于stack exchange，提问作者ChrisOakes