AsyncLocal用于在async/await链中自动传递异步上下文数据，每个逻辑执行流拥有独立副本，值默认随ExecutionContext流动，适用于日志跟踪ID等场景，但不适用于跨线程或Task.Run场景。
AsyncLocal 是用来保存异步上下文数据的
它让变量在 async/await 链中“自动传递”，类似线程本地存储（ThreadLocal<t></t>），但作用域是逻辑执行上下文而非物理线程。常见于日志跟踪 ID、用户上下文、事务 ID 等需要跨 await 保持的数据。
关键点：它不共享状态，每个异步控制流拥有独立副本；值不会从父任务自动流入子任务，除非显式启用 flowExecutionContext = true（默认为 true）。
AsyncLocal 的值何时会被复制或重置
它的行为由 AsyncLocal<t>.Value</t> 的读写触发，并受 ExecutionContext 流动控制。默认情况下：
- 每次
await后，新延续（continuation）会继承调用前的AsyncLocal<t></t>值（即“复制”） - 若在
await后修改Value，只影响当前分支，不影响上游或并行分支 - 若构造
AsyncLocal<t></t>时传入new AsyncLocal<t>(true)</t>（已废弃），或使用带FlowExecutionContext = false的ExecutionContext.SuppressFlow()，则值不会流动 -
Value设为null不会触发ValueChanged回调；只有非空值变更才触发（且仅当回调注册了）
AsyncLocal 的 ValueChanged 回调容易被误用
注册 ValueChanged 是为了监听值变更，但它有严格限制：
- 回调在**值实际变更时触发**，不是每次读取都触发
- 回调中修改
Value会再次触发回调，可能造成死循环 - 回调执行时机不确定——可能在任意延续点，不能依赖执行顺序或线程上下文
- 若未保留对
AsyncLocal<t></t>实例的引用，它可能被 GC 回收，导致回调静默失效
var local = new AsyncLocal<string>();
local.ValueChanged += (s, e) =>
{
// ❌ 危险：这里再赋值会再次进入该回调
// local.Value = "reentrant";
// ✅ 安全：只做记录或轻量通知
Console.WriteLine($"Old: '{e.PreviousValue}', New: '{e.CurrentValue}'");
};
AsyncLocal 不是线程安全的替代品，也不能替代依赖注入
它解决的是“逻辑调用链中的隐式传递”问题，不是并发读写保护：
- 多个并发异步操作各自有独立副本，不存在竞态——但这不等于“线程安全”，而是“天然隔离”
- 它无法替代
IServiceScope或IHttpContextAccessor这类有生命周期管理的上下文访问方式 - 在 ASP.NET Core 中，
HttpContext已通过AsyncLocal<httpcontext></httpcontext>实现，但你不该自己再套一层来“存 HttpContext” - 高频创建/销毁
AsyncLocal<t></t>实例会影响性能，应复用静态实例
最常被忽略的一点：它无法跨越 Task.Run 或显式线程切换（如 ThreadPool.QueueUserWorkItem）保留值，除非手动捕获并恢复 ExecutionContext——而这种操作极少见，也极易出错。
