ThreadStatic 在 async/await 中会丢失值，因其仅绑定物理线程且不参与 ExecutionContext 流转；AsyncLocal 则通过 ExecutionContext 自动传播，适用于请求上下文等逻辑调用链场景。
![c# [threadstatic] 和 asynclocal<t> 在异步代码中的行为区别](https://img.php.cn/upload/article/001/221/864/176798384589505.png)
ThreadStatic 在 async/await 中会丢失值
ThreadStatic 仅绑定到物理线程，而 async/await 可能导致方法在不同线程上恢复执行。一旦 await 后续操作被调度到另一个线程（比如线程池线程），原线程上的 ThreadStatic 字段值就不可见了。
- 典型现象：
ThreadStatic字段在 await 前设为"A"，await 后读出来是null或默认值 - 即使未发生线程切换（如使用
Task.CompletedTask），.NET 也不保证恢复在线程原上下文，行为不可靠 - 它不参与
SynchronizationContext或ExecutionContext流转，完全被异步状态机忽略
AsyncLocal 自动随 async 方法传播
AsyncLocal<t></t> 的值通过 ExecutionContext 流转，只要没显式禁用（如用 Task.Run + ExecutionContext.SuppressFlow()），await 前后值保持一致。
- 适用于需要“逻辑调用链”隔离的场景，比如请求 ID、用户上下文、数据库事务作用域
- 注意：赋值操作（
Value = x）会触发拷贝 —— 修改引用类型实例内容不会自动传播，需重新赋值 - 与
CallContext.LogicalSetData类似，但类型安全且专为 async 设计
两者不能混用替代，选错会导致静默错误
把 ThreadStatic 当作“异步局部变量”用，代码在同步路径下看似正常，一加 await 就出问题；反过来用 AsyncLocal<t></t> 替代纯同步线程局部存储，会引入不必要的 ExecutionContext 开销，且在某些受限环境（如中断上下文、高吞吐 I/O 循环）可能有性能影响。
- 同步密集型库（如高性能解析器）仍适合
ThreadStatic，前提是确认永不进入 async 路径 - ASP.NET Core 中间件、EF Core 审计日志、OpenTelemetry 上下文传递等，必须用
AsyncLocal<t></t> - 不要在
AsyncLocal<t>.Value</t>中存可变对象并直接修改其属性 —— 下游 await 后看到的仍是旧引用，值未更新
static class ContextDemo
{
[ThreadStatic] static string _threadLocal;
static AsyncLocal<string> _asyncLocal = new();
public static async Task ShowDifference()
{
_threadLocal = "from thread";
_asyncLocal.Value = "from async";
await Task.Yield(); // 切换执行点
Console.WriteLine(_threadLocal); // null（几乎总是）
Console.WriteLine(_asyncLocal.Value); // "from async"
}
}
AsyncLocal 的 Dispose 不会自动清理跨 await 的值
AsyncLocal<t></t> 本身不实现 IDisposable，它的生命周期由 .NET 运行时管理。你调用 _asyncLocal.Value = null 并不能“清除”所有嵌套 async 上下文中的副本 —— 每个 await 分支都持有一份独立拷贝。
- 若需显式清理（如避免内存泄漏），应在逻辑结束时手动设为
null，并在关键路径做空值检查 - 尤其注意循环或递归 async 调用中重复赋值，可能导致意外覆盖或残留
- 没有类似
using的语法糖，得靠代码约定或封装辅助类来保障清理时机
