ExecutionContext.SuppressFlow 是干什么的
它用来临时禁止当前线程的
ExecutionContext向异步操作（比如
Task.Run、
await后续延续）或新线程（比如
ThreadPool.QueueUserWorkItem）自动传递。这包括
CallContext（.NET Framework）、
AsyncLocal<t></t>、安全上下文、事务等所有绑定到执行上下文的数据。
默认情况下，.NET 会“流动”（flow）这些上下文，确保异步链中能访问到原始请求的用户身份、追踪 ID、日志范围等。但有些场景你明确不需要——比如后台轮询任务、内部线程池工作项、或已显式重置上下文的中间件。
什么时候该用 SuppressFlow
在已知不会访问 AsyncLocal<t></t>
或不依赖请求上下文的后台任务中，避免无谓拷贝
ASP.NET Core 中，某些中间件在 await
前调用 SuppressFlow
，防止把 HTTP 请求上下文意外带入非请求生命周期的异步分支
高频短时任务（如每毫秒调度一次的定时器回调），上下文流动开销可测
var flow = ExecutionContext.SuppressFlow();
try
{
await Task.Run(() => { /* 不需要原始 AsyncLocal<string> 的逻辑 */ });
}
finally
{
ExecutionContext.RestoreFlow();
}
注意：必须配对使用
SuppressFlow和
RestoreFlow，否则可能引发未定义行为或跨异步边界的上下文污染。
性能影响到底有多大
单次调用 SuppressFlow
本身开销极小（纳秒级），本质是设置一个线程本地标记
真正省下的成本，是在后续每次异步延续或线程切换时跳过整个上下文捕获与还原流程
在压测中，对高频 await
场景（如每秒数万次轻量异步调用），可观测到 3%~10% 的 CPU 时间下降，主要来自减少 AsyncLocal<t></t>
的 slot 拷贝和弱引用管理
但它不加速业务逻辑本身，只减少上下文传播的间接开销；如果业务代码本身有锁、IO 或 GC 压力，这点优化会被淹没
常见误判点：
认为加了SuppressFlow就能“提升异步性能” → 实际只影响上下文流动路径 在需要
AsyncLocal<t></t>的地方（如日志
BeginScope、EF Core 的变更跟踪）错误地压制 → 导致上下文丢失、数据错乱 忘记
RestoreFlow→ 后续所有异步操作都失去上下文流动能力，且无法恢复（除非线程退出重建）
比 SuppressFlow 更安全的替代方案
多数时候，你真正想要的不是全局压制，而是局部隔离：
使用AsyncLocal<t>.Value = default</t>显式清空特定值，而非压制整个上下文 在
Task.Run时传入自定义
TaskScheduler或用
Task.Factory.StartNew(..., TaskCreationOptions.DenyChildAttach)控制延续行为 ASP.NET Core 中优先用
HttpContext.RequestServices+ 作用域服务，而非依赖
AsyncLocal<t></t>传递状态
压制执行上下文是个低级别开关，生效范围粗、副作用隐晦。它解决的是“不能流动”的问题，而不是“不该流动”的设计问题。真要优化，先确认是否真的在流动不需要的东西。
