C#中CallContext能否存储多键？为何自定义_d2_键读取始终为空？

CallContext 从设计上就支持存储2个及以上不同名称的键值对，不存在单个逻辑上下文最多存1个数据槽的限制。你遇到的d2始终读取为null、每次都要重新初始化的问题，和CallContext本身的多键支持能力无关，核心原因通常集中在以下几个点：

根本原因定位 #

1. 低级拼写错误排查
   先核对两段代码里的存储键名，确认复制代码后没有粗心把_d2_写成和d1相同的_d1_键名——如果键名完全一致，后写入的值会直接覆盖先写入的实例，不会出现读不到d2的现象。
2. 本地数据与逻辑上下文的流转差异
   这是该类问题最高发的原因：
   CallContext提供了两套完全独立的数据存储机制，在纯同步代码场景下两套方法的表现完全一致，一旦涉及异步流转就会出现明显差异：
   • 普通模式：通过SetData/GetData读写的是本地线程槽数据，这类数据仅对当前执行的物理线程有效，一旦代码执行过程中出现async/await异步切换、线程池调度切换、新的请求上下文创建，这部分数据会直接丢失，不会自动传递到新的执行上下文。
     你碰到的d1能正常读取、d2读不到的差异，本质是两段代码的执行路径不同：d1的初始化和后续读取都在同一个连续的同步执行上下文里，没有发生线程切换，所以能稳定读到之前存的实例；而d2的初始化和读取操作中间穿插了异步流转、线程切换，导致本地线程槽里的_d2_数据已经被清空，每次读到的都是null。
   • 逻辑模式：通过LogicalSetData/LogicalGetData读写的是跨线程的逻辑上下文数据，这类数据可以在整个异步调用链中流转，不会因为线程切换丢失。
3. 主动的数据清除逻辑冲突
   排查你项目的管线中间件、请求结束的收尾逻辑，是否存在主动调用CallContext.FreeNamedDataSlot(key)释放指定数据槽的代码。如果释放逻辑的列表里只包含_d2_对应的槽位、没有包含_d1_，就会出现d1实例长期保留、d2每次请求都被重新初始化的现象。

修正参考 #

• 涉及异步流转的场景，将原来的SetData/GetData替换为LogicalSetData/LogicalGetData，确保多键存储的数据可以跨上下文稳定传递。
• 全项目搜索FreeNamedDataSlot的调用点，核对需要释放的键列表，避免漏配导致的数据异常。
• 确认两个静态属性的键名没有拼写错误，从根源上避免键名冲突问题。

内容的提问来源于stack exchange，提问作者thepasserby