异步方法调用后保留AsyncLocal值：ExecutionContext方案是否安全？

假设我有一个异步方法Task Parent()，它调用同步方法void Child()。Child()方法会设置某个AsyncLocal的值，在Child()返回后，它设置的AsyncLocal值在Parent()的剩余代码及其调用的所有方法中都可见。

现在如果将void Child()改为Task Child()并在Parent()中await它，Child()对AsyncLocal的修改将不再对Parent()可见。这是预期行为，因为每个异步段在创建时都会获得AsyncLocal上下文的独立副本（实际是接收原始副本，首次写入时复制），因此Child()修改的是独立的AsyncLocal实例。但如果我希望保留该值该怎么办？

我考虑了两种方案：一种是使用简单的Box<T>作为指针，每个异步段获取同一个box，但修改box的内容；这种方法可行，但Parent()需要提前准备好该box。另一种我更倾向的方案是修改Child()，使其通过return ExecutionContext.Capture()返回Task<ExecutionContext>，Parent()只需在awaitChild()后恢复该上下文。这样无需知晓所有AsyncLocal即可恢复全部值。

我想询问：第二种方案是否安全？它是否是解决该问题的标准做法？有哪些需要注意的陷阱或隐患？

注：Parent()并不知晓AsyncLocal的存在，Parent()在调用Child()后调用的其他方法需要访问该AsyncLocal值。

方案安全性 #

直接捕获并恢复ExecutionContext是安全的，但必须用ExecutionContext.Run()方法包裹需要使用该上下文的代码块——这个方法会在执行完代码后自动恢复原上下文，避免出现上下文污染的问题。如果手动替换上下文，反而容易引发意外错误。

是否为标准做法 #

这不算常规的标准解决思路。大部分场景下，开发者会优先选择传递显式状态（比如你提到的Box<T>或自定义上下文对象），这种方式更直观、可读性更强，也不容易出现意外的上下文覆盖问题。捕获ExecutionContext属于相对底层的操作，一般只有框架级代码会用到这种方式。

陷阱与隐患 #

• 上下文污染风险：如果不用ExecutionContext.Run()而是直接替换当前上下文，后续代码可能会意外使用错误的上下文，尤其是在多线程或嵌套异步场景下，会引发难以排查的bug。
• 冗余上下文数据：ExecutionContext不仅包含AsyncLocal，还会捕获安全上下文、调用上下文等其他信息，恢复时可能引入你不需要的状态，甚至导致权限、环境相关的问题。
• 异步嵌套副作用：如果Parent()在恢复上下文后还有其他await操作，新的异步段会基于恢复后的上下文创建副本，这可能不符合你的预期——你可能只希望Child()后的特定代码使用该上下文，而非整个后续流程。
• 版本兼容性差异：虽然ExecutionContext是.NET核心API，但.NET Framework和.NET Core/.NET 5+在上下文捕获的细节上有细微差异，跨版本使用时需要额外测试验证。

替代建议 #

如果Parent()不需要知晓具体的AsyncLocal，可以让Child()返回一个"上下文恢复器"委托，而非直接返回ExecutionContext，这样更安全易用：

public delegate void ContextRestorer();

public async Task<ContextRestorer> Child()
{
    // 修改AsyncLocal的逻辑
    var updatedContext = ExecutionContext.Capture();
    return () => ExecutionContext.Run(updatedContext, _ => { }, null);
}

Parent()只需调用返回的委托，就能在指定代码块中使用Child()修改后的上下文。

内容的提问来源于stack exchange，提问作者Boris B.