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

C#事务：从“形同虚设”到“真正可靠”的完整指南

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

先说一个核心结论：在C#中处理事务，千万别把它想象成一个“全局开关”，一打开就万事大吉。实际上，它是一套需要精确组装的机制。事务必须与SqlConnection、SqlTransaction（或者EF Core中的DbContext.Database.BeginTransaction()）进行显式绑定。更重要的是，所有参与数据库操作的命令——无论是SqlCommand还是EF Core的Sa veChanges()——都必须共享同一个连接和事务上下文。漏掉其中任何一个环节，你精心设计的事务逻辑就可能悄然失效，导致数据不一致。

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

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

这个问题太常见了。根源往往在于：多个SqlCommand实例使用了不同的数据库连接对象，或者，虽然创建了事务，却没有把它显式地赋值给每一个命令的Transaction属性。

• 这里有个关键细节：SqlCommand默认是不关联任何事务的。即使你已经调用了connection.BeginTransaction()，也必须手动进行绑定：

  cmd.Transaction = transaction;

• 另一个典型的“坑”是作用域问题。如果你在using块内创建了SqlCommand，却在块外才去设置它的Transaction属性，就会触发一个InvalidOperationException异常，提示“当分配给命令的连接处于挂起的本地事务时，ExecuteNonQuery要求命令具有事务”。
• 此外，连接对象的生命周期管理也至关重要。如果在事务执行过程中，连接被意外关闭或释放（例如提前调用了connection.Close()或Dispose()），事务会自动回滚，但系统可能不会抛出异常。这种静默失败很容易让人误以为操作成功了。

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

在EF Core中开启事务后，其作用范围是明确的：仅限于当前这个DbContext实例后续通过Sa veChanges()（或异步版本）所生成的所有SQL语句。当然，前提是数据库连接没有被其他线程复用，也没有在事务中途被释放。

• 需要理解的是，事务的生命周期是绑定到DbContext背后的那个具体连接上的，而不是绑定到代码的作用域或者当前线程。这意味着，如果你在别处新建了一个DbContext，它天然就不在之前的事务范围内。
• 对于执行原生SQL的情况：使用context.Database.ExecuteSqlRaw()方法，它会默认参与到当前DbContext的事务中。但是，如果你通过context.Database.GetDbConnection().CreateCommand()这种方式自己创建了一个命令对象，那么就必须手动设置command.Transaction属性，否则它就是“脱管”状态。
• 这里有个重要的边界问题：跨多个DbContext实例的操作（比如两个独立构造的DbContext对象）是无法通过单一的BeginTransaction()来保证原子性的。这种场景下，需要考虑使用TransactionScope（分布式事务）或者在业务层设计补偿机制，生搬硬套BeginTransaction()是行不通的。

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

那么，TransactionScope的用武之地在哪里呢？答案是：当你需要协调多个独立的数据库连接、多个不同的DbContext实例，甚至是混合了EF Core和原生ADO.NET操作，并且要求这些操作作为一个原子单元全部成功或全部失败时，TransactionScope几乎是唯一可靠的选择。当然，这需要数据库支持并正确配置了MSDTC（分布式事务协调器），或者使用SQL Server 2019及以上版本提供的轻量级事务。

• TransactionScope的核心原理是基于“环境事务”（ambient transaction），它能自动将多个本地事务提升为一个分布式事务。不过话又说回来，在纯粹的单数据库操作场景下使用它，可能会引入不必要的性能开销和配置复杂度。
• 使用TransactionScope时有一个常见的性能陷阱：它的默认隔离级别是Serializable，这是最严格、最“重”的级别，很容易导致大量的锁和阻塞。因此，通常建议显式指定一个更合适的隔离级别，例如：

  new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted })

• 最后，流程控制必须严谨：务必在所有数据库操作都成功完成后，先调用scope.Complete()，然后再处理Dispose()。如果忘记调用Complete()，事务会在Dispose时静默回滚。同时，确保using块的范围覆盖了所有相关的数据库操作，而不仅仅是DbContext的创建部分。

说到底，事务真正的难点，往往不在于语法怎么写，而在于如何准确判断“哪些操作必须放在同一个事务里”。举个例子，更新订单状态和发送一条消息通知，在业务逻辑上是一体的，但消息中间件（如RabbitMQ、Kafka）通常不支持两阶段提交协议。如果强行把它们塞进同一个数据库事务，只会让整个系统变得更加脆弱。因此，厘清事务的边界，远比死记硬背语法重要得多。