c#如何使用事务_c#事务看这一篇就够了_保姆级教程-C#.Net教程-PHP中文网

C#事务需显式绑定SqlConnection与SqlTransaction（或DbContext.BeginTransaction），所有命令必须共享同一连接和事务上下文；否则将导致部分提交或静默回滚。

c#如何使用事务_c#事务看这一篇就够了_保姆级教程

直接说结论：C# 里事务不是“开个开关”就自动生效的，它必须和 SqlConnection、SqlTransaction（或 DbContext.Database.BeginTransaction()）显式绑定，且所有参与操作的命令（SqlCommand 或 EF 的 SaveChanges()）必须共享同一个连接和事务上下文——漏掉任一环节，事务就形同虚设。

为什么用 `SqlTransaction` 手动控制时还出现“部分提交”？

最常见原因是：多个 SqlCommand 实例用了不同连接对象，或没把 SqlTransaction 显式赋给每个命令的 Transaction 属性。

SqlCommand 默认不关联任何事务，即使你已调用 connection.BeginTransaction()，也必须手动赋值：
```
cmd.Transaction = transaction;
```
如果用了 using (var cmd = new SqlCommand(...)) 却在 using 外才赋 Transaction，会报 InvalidOperationException: ExecuteNonQuery requires the command to have a transaction when the connection assigned to the command is in a pending local transaction.
连接被意外关闭或释放（比如在事务中提前调用 connection.Close() 或 Dispose()），事务自动回滚但不抛异常，容易误判成功

EF Core 中 `BeginTransaction()` 后，哪些操作会被包含？

仅限该 DbContext 实例后续调用 SaveChanges()（或 SaveChangesAsync()）产生的 SQL —— 且前提是连接未被其他线程复用或中途释放。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

事务生命周期绑定到 DbContext 的连接状态，不是绑定到整个作用域或线程
如果在事务中执行原生 SQL（context.Database.ExecuteSqlRaw()），它默认参与当前事务；但若用 context.Database.GetDbConnection().CreateCommand() 自建命令，则必须手动设置 command.Transaction
跨 DbContext 实例的操作（比如两个不同 DbContext 对象）天然不共享事务，需用分布式事务（TransactionScope）或业务层补偿，别硬套 BeginTransaction()

什么时候该用 `TransactionScope` 而不是 `BeginTransaction()`？

当你需要跨多个数据库连接、多个 DbContext、甚至混合 EF + ADO.NET 操作，并保证原子性时，TransactionScope 是唯一靠谱选择（前提是数据库支持并开启 MSDTC 或 SQL Server 2019+ 的轻量级事务）。

TransactionScope 基于环境事务（ambient transaction），自动提升为分布式事务——但本地单库场景下可能引入不必要的性能开销和配置复杂度
常见坑：TransactionScope 默认隔离级别是 Serializable，比 ReadCommitted 更重，容易导致阻塞；建议显式指定：
```
new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted })
```
务必在 scope.Complete() 后再 Dispose()，否则事务静默回滚；且 using 块必须包住所有数据库操作，不能只包 DbContext 构造