C产品如何满足特定用户需求？

本文共计943个文字，预计阅读时间需要4分钟。

由于`BeginTransaction()`需要数据库连接已打开，而EF Core默认使用懒加载连接（lazy connection），直到执行查询或`SaveChanges()`时才会真正打开连接。如果直接调用`BeginTransaction()`而连接尚未打开，将抛出`InvalidOperationException: The connection is not open`异常。

解决方案是确保在调用`BeginTransaction()`之前连接已打开。如果连接是懒加载的，可以在执行查询或`SaveChanges()`之前显式打开连接。例如：

解决办法只有两个靠谱路径：

• 先触发一次轻量级操作让连接就绪，比如 await context.Database.CanConnectAsync() 或 context.Set<T>().Any()（注意：后者会发 SQL，仅适合开发/测试）
• 更稳妥、无副作用的做法：显式调用 await context.Database.OpenConnectionAsync()，再调用 BeginTransactionAsync()

别信“只要用了 SaveChanges 就一定连上了”——如果之前只做了 Add() 没 SaveChanges，连接依然没开。

事务必须绑定同一个 DbContext 实例

EF Core 的事务对象（IDbContextTransaction）和它的 DbContext 是强绑定的。你不能在一个 DbContext 上开启事务，然后把事务对象传给另一个新创建的 DbContext 实例去用——它不认识这个事务，SaveChanges(transaction) 会静默失败或抛出奇怪异常。

常见错误场景：

• 在 Repository 构造函数里 new 一个 DbContext，又在方法里 new 另一个，试图共享事务
• 依赖注入中注册了 Scoped 生命周期，但手动 new 出新实例绕过了 DI 容器
• 跨线程或异步分支里用了不同上下文实例

正确做法：整个事务生命周期内只用一个 DbContext 实例，且确保它没被提前 Dispose（比如别在 using 块里提前释放）。

混合执行 EF 操作和原生 SQL 时事务怎么保持一致？

当你既要 context.Products.Add()，又要 context.Database.ExecuteSqlRaw()，还希望它们在同一个事务里原子提交，关键不是“加个 transaction 参数”就完事——原生 SQL 默认走自己的连接和事务上下文。

必须显式把原生命令挂到当前事务上：

• 先拿到当前连接：var conn = context.Database.GetDbConnection()
• 确保它已打开：if (conn.State != ConnectionState.Open) await conn.OpenAsync()
• 创建 DbCommand，并设置 command.Transaction = transaction.GetDbTransaction()

漏掉最后一步，原生 SQL 就是独立事务，EF 那边回滚了它也不受影响。这是生产环境数据不一致的高频原因。

CommitAsync() 和 RollbackAsync() 是同步方法？不，但容易误用

CommitAsync() 和 RollbackAsync() 看名字像异步，实际是同步方法（返回 Task 仅为接口统一），但它们**必须在 await 链中调用**，否则可能触发死锁或资源竞争——尤其在 ASP.NET Core 同步上下文未禁用时。

典型误写：

await transaction.CommitAsync(); // ✅ 正确 transaction.CommitAsync(); // ❌ 忘记 await，后续逻辑可能读到未提交数据或报错

更危险的是在 catch 块里只 throw 不 await transaction.RollbackAsync()：事务卡在 pending 状态，连接池可能耗尽，下个请求直接超时。

最简健壮模板就是：用 using var transaction = await context.Database.BeginTransactionAsync(); + try/catch + 显式 await transaction.CommitAsync() 或 await transaction.RollbackAsync()。