DbContext不能直接当Unit of Work用，因其暴露EF实现细节导致业务层耦合、测试困难，且多实例下变更追踪不共享；真实UoW应只提供语义化方法并确保与DbContext生命周期一致。
为什么 DbContext 不能直接当 Unit of Work 用
Entity Framework 的 DbContext 看起来天生就是工作单元（Unit of Work）的完美候选——它能跟踪变更、批量提交、管理对象生命周期。但问题恰恰出在这里：如果直接把 DbContext 当作 UoW 接口暴露给业务层，无异于埋下了耦合与测试的定时冲击波。一个典型的后果是，业务逻辑会深度绑定 EF 的实现细节，比如直接操作 DbContext.Entry(entity).State = EntityState.Modified，导致仓储层的方法几乎无法被模拟（Mock），集成测试更是举步维艰。另一个常见误区是，在一个请求周期内创建了多个 DbContext 实例，却误以为它们共享同一套变更追踪，结果调用 Sa veChanges() 时，只有部分修改被提交到了数据库。
- 核心原则是：不要把
IUnitOfWork接口设计成DbContext的简单翻版，尤其要避免直接暴露Set或底层的() ChangeTracker。 - 一个设计良好的 UoW 应该只提供业务语义明确的方法，例如
CompleteAsync()用于提交，或者RegisterForUpdate（如果确实需要手动标记更新）。(T entity) - 在 ASP.NET Core 的依赖注入体系中，务必确保将
DbContext和自定义的IUnitOfWork都注册为Scoped生命周期，并且保证它们在同一个服务作用域内使用的是同一个实例。
如何让仓储（Repository）真正配合 Unit of Work
仓储模式存在的意义，并非仅仅是封装 DbSet 的工具类。它的一个根本前提是：所有数据操作都必须经由当前活跃的 UoW 来协调。否则，很容易陷入“仓储自己偷偷 new 一个 DbContext 提交数据，而 UoW 对此一无所知”的混乱局面。
- 仓储的构造函数应该接收
IUnitOfWork接口，而不是具体的DbContext。仓储内部操作所需的DbSet，例如_context.Set，必须从 UoW 所持有的那个统一上下文实例中获取。() - 仓储层不应该提供
Sa ve()或类似的方法。保存动作的发起权必须牢牢掌握在 UoW 手中，由它来统一触发，否则事务的边界将彻底失控。 - 如果存在大量只读查询且不希望其参与 UoW 的变更追踪，一个常见的做法是设计独立的
IReadOnlyRepository。其内部可以使用一个轻量级的、独立的DbContext（配合AsNoTracking()查询，用完即释放），从而与主 UoW 完全隔离。
事务未回滚？检查 DbContext 的 Scope 和 Dispose 行为
“UoW 不生效”最直观的表现就是：代码抛出了异常，但数据库里却留下了部分脏数据。很多时候，问题的根源并非逻辑错误，而是 DbContext 的生命周期管理失去了控制。
- 虽然 ASP.NET Core 默认将
DbContext注册为Scoped，但如果在非托管线程（例如Task.Run内部）或手动创建new ServiceScope()时，没有正确传递或使用服务作用域，就会导致多个DbContext实例并存。此时，UoW 的Sa veChanges()可能只对其中的一个实例生效。 - 显式调用
Dispose()或者过早使用await using会直接终结变更追踪器。后续再调用CompleteAsync()时，EF Core 通常不会报错，但也不会向数据库写入任何数据，造成静默失败。 - 当使用
Database.BeginTransaction()手动开启事务时，必须确保这个事务对象绑定的是当前 UoW 所持有的那个DbContext.Database属性，而不是另一个上下文实例的Database。
异步方法里 await CompleteAsync() 为什么还是同步阻塞
CompleteAsync() 的内部实现通常是调用 DbContext.Sa veChangesAsync()。但是，这个方法是否真的能实现异步 I/O，并不完全由代码决定，还取决于底层的数据库驱动配置。
- 首先检查数据库连接字符串。对于 SQL Server，确保包含了
Pooling=true; Async=true;等参数。某些旧版本的驱动（如System.Data.SqlClient）在特定环境下，可能会退化为用同步方式模拟异步操作。 - 切记，不要在调用
CompleteAsync()之前，无意中调用了同步的Sa veChanges()方法（哪怕是为了调试）。因为同步方法会提前刷新变更并清空 ChangeTracker，导致后续的Sa veChangesAsync()无事可做。 - 在跨库或多上下文场景中，如果 UoW 需要协调多个
DbContext，那么CompleteAsync()内部应该使用Task.WhenAll()来并行提交，而不是用await进行串行等待。否则，异步带来的性能优势可能反而会丧失。
说到底，工作单元模式的复杂性，并不在于其结构本身，而在于它恰好站在了 ORM 框架、依赖注入容器、事务传播和异步调度这四个领域的交叉点上。其中任何一个环节的配置出现偏差，都可能让“统一提交”这个核心承诺，变成一种不可靠的幻觉。
