为什么DbContext生命周期极短？该选scoped/singleton/transient？设为单例有何问题？

微软官方文档明确说明："DbContext实例被设计为用于单次工作单元（unit-of-work），这意味着DbContext实例的生命周期通常非常短"

一、推荐的生命周期选择 #

优先选择Scoped生命周期，仅在特定场景下可选择Transient生命周期，绝对不推荐使用Singleton生命周期，原因如下：

• Scoped生命周期在ASP.NET Core中对应单次请求创建一个实例，请求结束后自动销毁，刚好完美匹配DbContext单次工作单元的设计定位，不会出现同一请求内多个DbContext实例导致的数据状态不一致问题，也无额外的实例创建销毁开销。
• Transient生命周期每次请求注入时都会创建新的DbContext实例，虽符合短生命周期要求，但同一请求内多次注入会生成多个实例，可能导致同请求内实体跟踪状态不同步，还会增加额外的数据库连接开销，仅适合需要独立工作单元的特殊场景使用。

二、将DbContext设为Singleton会出现的问题 #

• 线程安全异常：DbContext本身未做线程安全设计，全局单例实例会被所有并发请求共享，多线程同时执行查询、写入等操作时会出现随机的并发冲突、未处理异常，甚至直接导致进程崩溃。
• 内存泄漏问题：DbContext内置的变更跟踪器会默认跟踪所有查询、修改过的实体对象，单例实例不会随请求结束释放，跟踪的实体数量会持续累积，内存占用不断升高，最终触发内存溢出（OOM）故障。
• 数据一致性故障：单例DbContext会长期缓存已查询到的实体状态，若其他进程/节点修改了数据库对应数据，该实例仍会返回本地缓存的过期数据，直接导致业务逻辑判断错误，引发脏数据问题。
• 事务管理混乱：不同请求的事务操作会共用同一个单例DbContext的连接和事务上下文，出现事务互相干扰、嵌套提交/回滚失败的问题，无法保证事务的ACID特性，严重破坏数据可靠性。

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