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实际使用中，最容易忽略的是异步场景下的上下文断裂，以及 Dispose 的遗漏。这两点不出问题时毫无征兆，一出就是偶发内存上涨或上下文丢失，排查成本远高于写的时候多加两行。
