EF Core 中 BeginTransaction 必须在已打开的连接上调用，推荐先 Database.OpenConnection() 再 BeginTransaction；事务需与同一 DbContext 绑定，SaveChanges 后需显式 Commit/Rollback；异步操作须全程 async/await 一致。
EF Core 中 BeginTransaction 的正确调用时机
必须在已打开的数据库连接上启动事务，否则会抛出 InvalidOperationException: No database provider has been configured for this DbContext 或 InvalidOperationException: The connection is not open。常见错误是直接在未调用 SaveChanges 前就执行 BeginTransaction，而此时 DbContext 可能尚未初始化连接。
实操建议：
- 先触发一次查询或调用
Database.EnsureCreated()/Database.CanConnect()确保连接已建立（开发期可选） - 更稳妥的做法：显式调用
Database.OpenConnection()，再调用Database.BeginTransaction() - 事务必须与同一个
DbContext实例绑定，跨 DbContext 实例无法共享事务
如何用 SaveChanges 和 Commit 配合事务
EF Core 默认每个 SaveChanges 是独立事务（autocommit 模式）。启用手动事务后，SaveChanges 不再自动提交，所有变更都暂存在当前事务中，直到显式 Commit 或 Rollback。
示例关键步骤：
var transaction = context.Database.BeginTransaction();- 执行多个
Add/Update操作 - 调用
context.SaveChanges()—— 此时 SQL 已生成并发送，但未提交 - 调用
transaction.Commit()完成持久化 - 发生异常时，必须调用
transaction.Rollback()，否则连接可能被标记为“不可用”
嵌套事务与 TransactionScope 的兼容性问题
EF Core 本身不支持真正的嵌套事务；多次调用 BeginTransaction 在同一连接上会抛出 InvalidOperationException: A transaction is already in progress。若业务逻辑涉及多层服务调用，容易误用 TransactionScope 导致连接争用或静默失败。
注意点：
-
TransactionScope默认使用RequiresNew隔离级别，在 EF Core 5+ 中需配合options.UseSqlServer(..., o => o.EnableRetryOnFailure())并确保连接字符串含Pooling=true - 混合使用
Database.BeginTransaction()和TransactionScope极易引发ArgumentException: The connection does not support MultipleActiveResultSets - 推荐统一风格：简单场景用
BeginTransaction+try/catch；复杂分布式协调才考虑TransactionScope，且需验证数据库是否启用 MSDTC 或使用弹性事务（如 Azure SQL 的弹性数据库事务）
异步事务操作中 SaveChangesAsync 与 CommitAsync 的配对要求
EF Core 6+ 支持 BeginTransactionAsync 和 CommitAsync，但它们不是“自动补全”关系——如果用了异步开始，就必须用异步提交/回滚，混用同步与异步方法会导致事务状态错乱，甚至出现 InvalidOperationException: This SqlTransaction has completed。
典型错误模式：
- 调用
await context.Database.BeginTransactionAsync()，却用transaction.Commit()（同步） - 在
using块中提前释放DbContext，导致事务对象引用失效 - 未 await
SaveChangesAsync()就进入下一步，造成脏读或丢失更新
事务生命周期必须严格包裹在同一个作用域内，且所有数据库操作（包括 SaveChanges 和 Commit）保持 async/await 一致性。
实际编码中最容易被忽略的是：事务对象本身不持有连接引用，它只依赖底层 DbConnection 的生命周期。一旦 DbContext 被释放或连接关闭，事务即失效，后续 Commit 将静默失败或抛出难以定位的异常。
