C#事务需显式绑定SqlConnection与SqlTransaction（或DbContext.BeginTransaction），所有命令必须共享同一连接和事务上下文；否则将导致部分提交或静默回滚。
直接说结论：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 —— 且前提是连接未被其他线程复用或中途释放。
- 事务生命周期绑定到
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构造
事务真正难的不是写法，而是判断“哪些操作必须进同一事务”——比如发消息和改订单状态，看似一体，但消息中间件往往不支持两阶段提交，这时候强行塞进事务只会让系统更脆弱。边界比语法重要得多。
