ThreadLocal 在 await 后失效，因其绑定物理线程而非逻辑执行流；AsyncLocal 依托 ExecutionContext 实现跨 await 值传递，但需避免内存泄漏、与 CancellationToken 耦合及误用 SuppressFlow。
异步代码里用 ThreadLocal 传上下文，基本等于没传——值在 await 后大概率变 null。
为什么 ThreadLocal 在 await 后失效
ThreadLocal 绑定的是物理线程，不是逻辑执行流。一旦 await 触发调度（比如 Task.Delay、File.ReadAllLinesAsync），后续代码很可能在另一个线程池线程上恢复执行，而那个线程从未设置过 ThreadLocal.Value，读出来就是默认值（null 或 default(T)）。
-
ThreadLocal<string>.Value</string>在await前设为"a.txt"，await后读出来是null - 即使你用
Task.Run(() => { ... })包一层，只要里面含await，照样丢值 -
ThreadLocal适合纯同步多线程场景，比如Parallel.ForEach中每个线程独立缓存计算结果
AsyncLocal 怎么做到跨 await 不丢值
AsyncLocal 依赖 ExecutionContext 流转，它把值和“逻辑调用链”绑定，而不是线程。父 async 方法设的值，子 async 方法、嵌套 await、甚至跨线程池线程都能看到同一份逻辑副本。
- 值在
await前后保持一致，前提是没被显式改写或离开当前异步作用域（如Task.Run未开启ExecutionContext流） - 父子异步方法间自动继承：父设
ctx.Id = 123，子方法直接读_ctx.Value.Id就是123 - 修改子方法里的
Value不会影响父方法的值（类似结构化克隆，非引用共享）
别踩这些坑：AsyncLocal 的实际限制
AsyncLocal 不是万能上下文容器，滥用会导致内存泄漏或语义错乱。
- 不要存大对象（如
FileStream、byte[]）——它只传递引用，不管理生命周期，容易让资源无法释放 - 避免和
CancellationToken耦合：别把文件路径塞进CancellationToken.Register回调里，取消时回调执行的上下文可能已变 -
ExecutionContext.SuppressFlow()会直接切断AsyncLocal传播，调试时看到值突然消失，先查有没有这行 - 第三方日志库（如 Serilog 的
LogContext）底层也是AsyncLocal，混用自定义AsyncLocal<T>时注意命名和作用域隔离
CallContext 已废弃，迁移必须做
CallContext.LogicalSetData 和 LogicalGetData 在 .NET Core 2.1+ 完全移除，且无兼容替代 API。旧项目搜索全部 CallContext 调用点，统一替换为 AsyncLocal<T> 实例。
- 替换不是简单改名：要确保
AsyncLocal实例是static readonly，避免每次 new 出新实例导致上下文隔离失败 - 不要在
using块里初始化AsyncLocal，它的生命周期应覆盖整个请求或处理链 - 如果原来用
CallContext存临时状态（如重试次数），现在要用AsyncLocal<int>+ 显式递增逻辑
真正难的不是选 AsyncLocal 还是 ThreadLocal，而是判断某个数据该不该放进异步上下文——它得是“随请求走”的，而不是“随线程走”的。放错地方，再对的类型也救不了。
