dbcontext不能直接当unit of work用，因其暴露ef实现细节导致业务层耦合、测试困难，且多实例下变更追踪不共享；真实uow应只提供语义化方法并确保与dbcontext生命周期一致。
为什么 DbContext 不能直接当 Unit of Work 用
Entity Framework 的 DbContext 看似天然符合工作单元（Unit of Work）定义——它跟踪变更、批量提交、管理生命周期，但直接把它当 UoW 接口暴露给业务层会埋下耦合和测试隐患。最典型的问题是：业务逻辑强依赖 EF 实现细节，比如调用 DbContext.Entry(entity).State = EntityState.Modified，导致仓储方法无法被 mock，集成测试写不下去；另一个常见现象是，在一个 HTTP 请求中多次 new DbContext，却误以为它们共享同一套变更追踪，结果 SaveChanges() 只提交了部分修改。
- 不要把
IUnitOfWork接口设计成DbContext的简单包装，尤其避免暴露Set<t>()</t>或ChangeTracker - 真实的 UoW 应只暴露业务语义明确的方法，如
CompleteAsync()、RegisterForUpdate<t>(T entity)</t>（若需手动跟踪） - 在 ASP.NET Core 中，务必把
DbContext和自定义IUnitOfWork注册为Scoped，且确保它们共享同一个服务作用域实例
如何让仓储（Repository）真正配合 Unit of Work
仓储不是“封装 DbSet 的工具类”，它的存在前提是：所有数据操作必须经由当前活跃的 UoW 协调。否则就会出现“仓储自己 new DbContext 提交，UoW 完全不知情”的经典错乱。
- 仓储构造函数必须接收
IUnitOfWork（而非DbContext），内部通过 UoW 获取对应DbSet，例如：_context.Set<tentity>()</tentity>应来自 UoW 持有的上下文 - 仓储不应提供
Save()方法——保存动作只能由 UoW 统一触发，否则事务边界失控 - 若需支持“仅查询不参与 UoW”，应另设
IReadOnlyRepository<t></t>，其内部使用独立轻量DbContext（AsNoTracking()+Dispose即走），与主 UoW 隔离
事务未回滚？检查 DbContext 的 Scope 和 Dispose 行为
最常见的“UoW 不生效”表现为：异常抛出后数据库仍有脏写入。根本原因往往不是逻辑写错，而是 DbContext 生命周期失控。
- ASP.NET Core 默认注册
DbContext为Scoped，但如果在非托管线程（如Task.Run）、或手动new ServiceScope()时没正确传递 scope，会导致多个DbContext实例并存，UoW 的SaveChanges()只作用于其中一个 - 显式调用
Dispose()或提前await using会终结变更追踪，后续CompleteAsync()将静默失败（EF 不报错，但什么也不存） - 使用
Database.BeginTransaction()手动开启事务时，必须确保该 transaction 绑定到当前 UoW 持有的DbContext.Database，而不是另一个实例的Database
异步方法里 await CompleteAsync() 为什么还是同步阻塞
CompleteAsync() 内部调用的是 DbContext.SaveChangesAsync()，但它是否真异步，取决于你有没有让 EF 连接字符串启用真正的异步 I/O。
- 检查连接字符串是否含
Pooling=true; Async=true;（SQL Server）或对应 provider 的异步开关；旧版 SQL Server 驱动（如System.Data.SqlClient）在某些 Windows 版本上会退化为同步模拟 - 不要在
CompleteAsync()前调用SaveChanges()（同步版），哪怕只是调试加的——它会提前刷新变更并清空 ChangeTracker，导致后续SaveChangesAsync()无事可做 - 若 UoW 包装了多个 DbContext（如跨库场景），
CompleteAsync()必须用Task.WhenAll()并行提交，而非await串行，否则性能反不如同步
UoW 的复杂性不在结构本身，而在于它被迫站在 ORM、DI 容器、事务传播、异步调度四者的交界处——任一环配置偏移，都会让“统一提交”变成幻觉。
