ThreadLocal构造时传null直接抛NullReferenceException；工厂函数仅首次访问Value时执行一次；必须显式Dispose防内存泄漏；AsyncLocal才支持async/await上下文流转。
ThreadLocal 初始化时传 null 会怎样
直接抛 NullReferenceException——因为 ThreadLocal<t></t> 构造函数不接受 null 值作为默认值提供器，且泛型类型 T 为引用类型时，Value 初始读取返回 null 是合法的，但你不能在构造时传 null 当作工厂委托。
正确做法是显式提供初始化逻辑：
- 用
new ThreadLocal<string>(() => "default")</string>，避免首次访问时为null - 若依赖外部状态，确保委托无副作用、线程安全（例如不共享可变静态变量）
- 值类型如
int默认初始化为0，但若想设为42，仍需传工厂：new ThreadLocal<int>(() => 42)</int>
ThreadLocal.Value 被多次读取是否每次都调用工厂函数
不会。工厂函数只在**当前线程首次访问 Value 属性时执行一次**，后续读取直接返回该线程缓存的值。
这正是它和普通局部变量的关键区别：它延迟初始化 + 每线程一份 + 自动隔离。
- 适合保存线程专属的昂贵对象（如
Regex、StringBuilder、数据库连接上下文） - 注意：如果工厂返回的是共享对象（比如静态
List<t></t>），那依然不是线程安全的——ThreadLocal只管“存储位置”隔离，不管里面存的东西本身是否可共享 - 若需每次获取都新建实例（极少见），应手动封装逻辑，不要依赖
ThreadLocal的自动行为
不调用 Dispose 可能导致内存泄漏
ThreadLocal<t></t> 内部持有对每个线程数据的强引用，.NET Framework 中若线程长期存活（如线程池线程），且 ThreadLocal 实例未被释放，其线程局部值不会被 GC 回收。
尤其在 ASP.NET（非 Core）、WinForms 后台线程等场景下容易踩坑。
- 务必在不再需要时调用
threadLocal.Dispose() - 推荐用
using语句块包裹（仅限生命周期明确的场景，如单次任务） - .NET Core / 5+ 对此做了优化，但仍建议显式释放——文档未承诺跨版本行为一致
- 若值类型是大对象（如
byte[]数兆），泄漏影响更明显
ThreadLocal 和 AsyncLocal 的核心区别在哪
根本不在“线程”，而在“执行上下文”：ThreadLocal 绑定物理线程，AsyncLocal<t></t> 绑定 ExecutionContext，能跨 await 流转。
这意味着：
- 在
async/await方法中，ThreadLocal.Value在await后可能变成另一个线程的值，甚至为初始值（因线程切换） - 若需在异步链路中保持上下文（如请求 ID、用户身份），必须用
AsyncLocal<t></t>，而不是ThreadLocal<t></t> - 两者不互换；混用会导致逻辑错乱，且无编译错误
- 没有“自动升级”机制——从同步迁移到异步时，
ThreadLocal必须重构成AsyncLocal
