为何TransactionScope内部事务隔离级别不可变更，而SQL事务可以？

首先得明确：你观察到的SQL Server和TransactionScope的行为差异，本质是两者的设计目标完全不同。

先看SQL Server的行为 #

SQL Server允许在事务执行过程中动态调整隔离级别，就像你给出的这段代码：

begin transaction
set transaction isolation level serializable;
select * from FooTable;
set transaction isolation level read committed;
select * from FooTable;
begin transaction
set transaction isolation level serializable;
select * from FooTable;
--transaction_isolation_level可观测为4（serializable）

这是因为SQL Server的事务是单数据库实例内的本地事务，调整隔离级别只是改变当前连接下锁的处理策略，整个事务的上下文还是可控的，不会涉及跨资源的协调问题。

再看TransactionScope的设计逻辑 #

TransactionScope是.NET提供的分布式事务抽象，它的核心目标是协调多个不同类型的资源（比如多个SQL Server数据库、Oracle数据库、MSMQ消息队列甚至自定义资源）参与同一个事务，背后依赖的是Windows的分布式事务协调器（DTC）。它抛出异常的原因主要有这几点：

• 跨资源的一致性要求：不是所有资源都支持事务中途修改隔离级别。比如有些数据库系统不允许这种操作，还有像消息队列这类非数据库资源，可能根本没有“隔离级别”的概念。TransactionScope作为统一的事务入口，必须保证所有登记的资源都能遵循一致的事务规则，所以干脆禁止在事务树中修改隔离级别——否则在多资源场景下会出现语义冲突，甚至导致事务失败。
• 嵌套事务的语义约束：当你使用TransactionScopeOption.Required创建嵌套的TransactionScope时，子Scope会直接加入到父事务中。这时候如果子Scope指定了不同的隔离级别，就会破坏父事务已经确定的隔离语义。TransactionScope的设计是让整个事务链共享同一个隔离级别，确保事务的ACID特性在全局范围内一致。
• 避免语义模糊：如果允许在TransactionScope中动态修改隔离级别，开发者很容易误解事务的实际行为——比如以为修改后所有后续操作都用新级别，但在分布式场景下，部分资源可能根本不生效，反而埋下bug。设计者选择抛出异常，是一种“fail fast”的设计理念，提前暴露问题，而不是隐藏潜在的不一致。

你写的这段C#代码触发异常，就是因为嵌套的transactionScope2试图用ReadCommitted级别加入已经是Serializable级别的父事务，违反了TransactionScope的全局一致性规则：

[Theory]
[AutoFixtureMagicToGetParameterInstances]
void ZmenaIzolacniUrovneVedeKVyjimce(IFooDao sut, Foo foo)
{
    var tranOpts = new TransactionOptions()
    {
        IsolationLevel = IsolationLevel.Serializable,
        Timeout = TimeSpan.FromSeconds(60)
    };
    var tranOpts2 = new TransactionOptions()
    {
        IsolationLevel = IsolationLevel.ReadCommitted,
        Timeout = TimeSpan.FromSeconds(60)
    };
    using (var transactionScope = new TransactionScope(TransactionScopeOption.Required, tranOpts))
    {
        sut.SelectFoos();
        using (var transactionScope2 = new TransactionScope(TransactionScopeOption.Required, tranOpts2))
        {
            sut.SelectFoos();
        }
    }
}

总结 #

你之前的误区是把TransactionScope当成了单个数据库事务的“包装器”，但实际上它是为分布式事务场景设计的统一抽象。哪怕你只用到了单个数据库，它依然会遵循跨资源的一致性规则，因为它的设计目标不是模拟单个数据库的灵活行为，而是保证多资源事务的可靠性和一致性。

内容的提问来源于stack exchange，提问作者Igand