C#中try与finally块是否保证运行在同一Task/执行上下文？

C# 从语言规范和CLR设计层面，都不保证try块和finally块始终运行在同一个Task或同一个执行上下文中。你想靠构造函数和Dispose自动共享执行上下文来清理AsyncLocal的写法，在纯同步场景下碰巧能跑通，但在异步代码、线程切换场景下必然出问题。

首先纠正一个常见认知偏差 #

你提到using会把对象构造函数放入try块，这个说法不符合C#的标准实现。using语句的实际展开逻辑如下，构造函数的执行是在try块之外的：

// 先执行构造，完全在try结构外
var o = new Scope();
try
{
    // using块内的业务代码
}
finally
{
    // 非空判断后调用Dispose
    if (o != null) o.Dispose();
}

也就是说，从语法展开层面，构造函数的执行阶段连try的保护范围都没进，更谈不上和finally块做上下文绑定。

为什么不存在同上下文/同Task的强制保证 #

• try/finally本质是纯控制流结构，它唯一的契约是：只要控制流正常离开try块（包括正常执行结束、抛异常、return/break/continue跳转），finally块的代码一定会被执行。规范从头到尾没有提过finally必须和try跑在同一个线程、同一个Task、绑定同一个执行上下文。
• 异步场景下这个差异会非常明显：如果try块内存在await操作（尤其是带ConfigureAwait(false)、或者await Task.Run()这类会触发线程池调度的写法），finally块的代码大概率会跑在和try入口不同的线程池线程上。虽然AsyncLocal会随着执行上下文流转做拷贝，但这种流转是单向的，你在finally块里对AsyncLocal的修改只会作用在当前上下文拷贝上，根本不会回传到构造函数执行时的原始上下文。
• 极端场景下（比如异步操作取消触发跨线程栈展开、宿主强制中止工作线程），finally块甚至可能和构造函数的执行线程没有任何生命周期关联。

纯同步代码里你观察到的try和finally同线程、同上下文，只是同步执行流串行执行的附带效果，属于没有文档承诺的实现细节，只要代码里引入任何可能切换线程的逻辑，这个表现就会立刻打破，绝对不能把业务逻辑建立在这个前提上。

针对AsyncLocal清理场景的可靠实现 #

不要依赖执行上下文的自动共享，正确的做法是把需要的状态直接存在IDisposable对象的实例字段里——对象实例在using生命周期内是固定的，完全不受线程切换、上下文流转的影响：

public class Scope : IDisposable
{
    private readonly AsyncLocal<string> _asyncLocal;
    private readonly string _cachedOriginalValue;
    private bool _disposed;

    public Scope(AsyncLocal<string> asyncLocal, string scopedValue)
    {
        _asyncLocal = asyncLocal;
        // 构造时直接把赋值前的原始值存在实例字段里
        _cachedOriginalValue = asyncLocal.Value;
        asyncLocal.Value = scopedValue;
    }

    public void Dispose()
    {
        if (_disposed) return;
        // 直接用实例缓存的原始值恢复，完全不依赖当前执行上下文
        _asyncLocal.Value = _cachedOriginalValue;
        _disposed = true;
    }
}

这种写法不管Dispose在哪个线程、哪个执行上下文被调用，都能正确完成AsyncLocal的清理和值恢复，是.NET里做AsyncLocal作用域的标准实现方式。

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