EF Core 手动控制事务的核心在于显式开启、明确提交或回滚，而不是依赖默认行为。关键点是：事务不会自动提交，必须显式调用 Commit()；若未提交且 using 块结束，会自动回滚。
显式开启并管理事务
使用
Database.BeginTransaction()启动事务，配合 try-catch 确保异常时回滚： 用
using var transaction = context.Database.BeginTransaction();确保资源释放 在
try块中执行所有数据库操作（如 Add + SaveChanges） 仅当全部成功才调用
transaction.Commit()在
catch中必须调用
transaction.Rollback()，再重新抛出异常
支持异步操作的写法
高并发或 Web API 场景推荐异步事务：
用BeginTransactionAsync()替代同步方法 SaveChanges 对应使用
SaveChangesAsync()Commit 和 Rollback 本身是同步方法，但需放在 await 链之后 避免在异步方法中混用同步事务 API，以防死锁
事务中执行原生 SQL 或混合操作
事务可包裹 EF Core 操作与 ADO.NET 原生命令（前提是共用同一连接）：
先获取底层连接：var connection = context.Database.GetDbConnection();确保连接已打开（
if (connection.State != ConnectionState.Open) await connection.OpenAsync();） 创建 command 并设置
command.Transaction = transaction.GetDbTransaction();这样原生 SQL 就和 EF 的 SaveChanges 处于同一事务边界内
常见陷阱与规避方式
手动事务容易出错的地方集中在生命周期和异常处理上：
忘记调用Commit()→ using 结束自动回滚（看似“失败”，实为保护机制） 在 catch 中只 throw 不 rollback → 事务可能仍处于活动状态，后续操作报错 跨多个 DbContext 实例使用同一事务 → 不支持，每个上下文需独立开启事务或改用 TransactionScope DbContext 被设计为短生命周期，不要复用已提交/回滚过的事务对象
基本上就这些。核心就三点：显式开启、成功才提交、异常必回滚。不复杂但容易忽略细节。
