asynclocal比threadlocal更合适异步文件操作，因其随异步上下文流转、跨await保持值；而threadlocal在线程切换后丢失值，且callcontext已废弃；应封装结构化上下文并避免存大对象或资源。
异步文件操作中 AsyncLocal<t></t> 为什么比 ThreadLocal<t></t> 更合适
因为 ThreadLocal<t></t> 在 await 后线程可能切换，值会丢失；而 AsyncLocal<t></t> 跟随异步上下文流转，能跨 await 持续携带文件路径、请求 ID 或日志标记等上下文。
-
AsyncLocal<t></t>的值在await前后保持一致，只要没显式重置或离开逻辑调用链 -
ThreadLocal<t></t>在 ThreadPool 线程切换后就断了——比如File.ReadAllLinesAsync内部调度到另一线程时，值直接为空 - 不要在
AsyncLocal<t></t>中存大对象（如整个FileStream），它只是引用传递，不控制生命周期 - 示例：用
AsyncLocal<string></string>传当前处理的文件名
private static readonly AsyncLocal<string> _currentFilePath = new(); // 开始处理前设置 _currentFilePath.Value = @"C:\logs\2024-06-12.txt"; await ProcessLineAsync(); // 内部仍可读 _currentFilePath.Value
避免 CancellationToken 和文件上下文耦合导致的意外取消
把文件路径、重试次数等上下文硬塞进 CancellationToken（比如用 CancellationToken.Register 触发清理）容易出问题：取消信号可能早于文件操作完成，导致上下文被提前清除或资源误释放。
-
CancellationToken只该表达“是否应该中止”，不该承载业务上下文数据 - 若需取消时清理临时文件，应单独监听
CancellationToken并在回调里用独立变量访问上下文，而不是依赖AsyncLocal当时的值（可能已被覆盖） - 常见错误：在
using var stream = File.OpenRead(path)外围用try/catch (OperationCanceledException)，但没保存path到局部变量，异常处理时 path 已不可靠
用 CallContext.LogicalGetData？别用了，.NET Core+ 已废弃
CallContext.LogicalGetData 在 .NET Framework 里能跨异步传递，但在 .NET Core 2.1+ 中已被移除且无替代 API——它不是跨平台设计，也不受 AsyncLocal 的语义保证。
- 如果你在迁移旧项目，搜索代码里的
CallContext.LogicalSetData并替换成AsyncLocal<t></t> - 不要试图用
ExecutionContext.SuppressFlow()来“优化”上下文传递——它会直接切断AsyncLocal流转，文件操作中途就丢上下文 - 第三方库（如 Serilog 的
LogContext）底层也基于AsyncLocal，可复用，但注意不要和自定义上下文冲突
结构化上下文建议：封装成 FileOperationContext 类
直接用 AsyncLocal<string></string> 或 AsyncLocal<int></int> 容易散落、难维护。把文件路径、超时配置、重试计数、关联 trace ID 封装成一个不可变类，再用 AsyncLocal<fileoperationcontext></fileoperationcontext> 管理，更可控。
- 构造函数设为私有，用静态工厂方法创建，确保字段只读
- 避免在
FileOperationContext中持有Stream或MemoryStream实例——它们不是上下文，是资源，该用using或IAsyncDisposable - 如果上下文需要跨进程（如写入消息队列后再由另一服务处理），
AsyncLocal生效范围仅限当前进程内，此时必须序列化上下文字段并随消息一起传递
真正容易被忽略的是：上下文不是万能胶。它解决不了跨线程池、跨进程、跨机器的传递问题——那些场景下，路径、ID、参数必须作为显式参数层层透传，或者走外部存储（如 Redis）协调。
