是的，async 方法默认捕获 ExecutionContext 以保证 AsyncLocal<T> 等逻辑上下文跨 await 正确传递；开销包括内存分配、复制与还原，空 await 约20–50 ns，含 AsyncLocal 或 HttpContext 时可达微秒级；禁用需用 ExecutionContext.SuppressFlow() 配合 try/finally，ConfigureAwait(false) 无效；仅纯 I/O 且无上下文依赖的底层库场景才建议禁用。
async 方法默认会捕获 ExecutionContext 吗？
是的，await 表达式在默认情况下会捕获当前线程的 ExecutionContext（包括 CallContext、同步上下文、安全上下文等），并在恢复时还原。这是为了保证 AsyncLocal<T>、LogicalCallContext 等逻辑上下文能跨 await 边界正确传递。
捕获 ExecutionContext 的开销有多大？
开销主要体现在三方面：
-
内存分配：每次捕获会创建新的
ExecutionContext实例（内部包含多个字段副本），尤其在高频await场景（如高吞吐 I/O 循环）下易引发 GC 压力 -
复制成本：若当前上下文含大量
AsyncLocal<T>数据或自定义ILogicalThreadAffinative对象，深拷贝耗时明显 -
还原开销：恢复时需逐个调用
SetData或触发OnAsyncLocalValueChanged回调，可能间接触发用户代码
实测显示，在无上下文变更的空 async 方法中，单次 await 的额外开销约 20–50 ns；但一旦存在活跃的 AsyncLocal<string> 或 ASP.NET Core 的 HttpContextAccessor，可升至数百纳秒甚至微秒级。
如何禁用 ExecutionContext 捕获？
使用 ConfigureAwait(false) 是最常用方式，但它只影响 SynchronizationContext 和 TaskScheduler，不阻止 ExecutionContext 捕获 —— 这点常被误解。
真正禁用 ExecutionContext 捕获需配合 TaskCreationOptions.RunContinuationsAsynchronously 或更直接的方式：手动切换到无上下文环境：
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
public static async Task DoWorkAsync()
{
// 在 await 前清除 ExecutionContext
var originalContext = ExecutionContext.Capture();
ExecutionContext.SuppressFlow(); // 关键：禁用后续捕获
<pre class='brush:php;toolbar:false;'>try
{
await Task.Delay(10);
// 此处已无 ExecutionContext，AsyncLocal 不可见
}
finally
{
ExecutionContext.RestoreFlow(); // 恢复（仅限当前线程）
}}
注意：SuppressFlow() 是线程局部操作，且不能跨 await 边界自动恢复 —— 所以必须用 try/finally 保证成对调用。若方法内有多处 await，每处前都需检查是否仍处于 suppressed 状态。
什么场景下值得禁用？
仅当同时满足以下条件时才建议考虑：
- 方法纯属 I/O 等待，**完全不依赖**
AsyncLocal<T>、HttpContext、TransactionScope等上下文数据 - 性能剖析确认
ExecutionContext捕获是热点（如 dotTrace / PerfView 显示ExecutionContext.Capture占比高） - 调用链上游不会因禁用而破坏逻辑（例如 ASP.NET Core 中间件里禁用会导致
HttpContext丢失）
多数业务代码无需干预；库作者在编写底层异步工具（如高性能 socket 封装、序列化器）时，才可能需要精细控制。
真正容易被忽略的是：即使你没显式用 AsyncLocal，ASP.NET Core、EF Core、NLog 等框架已在后台注入了上下文 —— 盲目 SuppressFlow 很可能让日志 MDC、数据库事务、请求 ID 跟踪全部失效。
