我目前有一个WCF服务用于执行一些数据库查询和发送邮件。长话短说，这两种方法都是在实现中的某个地方同步使用HttpContext.Current。
我最初的问题是在第一次await之后，HttpContext.Current变为null，因此，第二次操作失败。我在Google上搜索了几个小时，我测试了我发现的所有内容...自定义同步上下文，web.config中的appSettings，针对.NET 4.5，启用ASP.NET兼容性，但没有任何效果。
然后，我发现this SO post谈论CallContext。基本上，这个想法是将HttpContext.Current存储在CallContext中。我测试了，yeepee，它的工作原理。但是，由于我不知道究竟是什么CallContext，我读到了它。
我不确定我是否真的理解了所有内容，但在阅读之后，我有一个担忧。我可能错了，但似乎无法保证一旦异步调用完成后线程恢复与初始线程相同。问题是我在HttpContext中存储了几个值，我担心第一个方法用用户A值执行，然后，一旦异步调用完成，第二个方法用用户B值执行（如HttpContext）不会是一样的）。
我想人们很想告诉我只将这些值存储在CallContext中，但我在面对WCF问题之前创建了一个完整的架构，所以我不想完全复习它，这就是为什么CallContext方便的变化很小。
有人能告诉我我的理论是否正确吗？
WCF是一种完整的SOA体系结构，为您提供了多种协议支持，并且一切都是可配置的，您还可以扩展自定义所有内容。因此，获取所有内容非常棘手。只需要基础知识：
三种类型的WCF并发性是：
单一：单个请求在给定时刻可以访问WCF服务对象。
多个：在这种情况下，WCF服务对象可以在任何给定的时刻处理多个请求。
可重入：单个请求线程可以访问WCF服务对象，但线程可以退出WCF服务以调用另一个WCF服务，也可以通过回调调用WCF客户端并重新进入而不会出现死锁。
看起来很简单，但等待它具有与并发性不同的实例化模式：
- 每次调用为每个客户端请求创建一个新的InstanceContext（以及服务对象）。
- 每个会话为每个新客户端会话创建一个新的InstanceContext（以及服务对象），并在该会话的生命周期内进行维护（这需要一个支持会话的绑定）。
- 单实例：单个InstanceContext（以及服务对象）处理应用程序生命周期内的所有客户端请求。
默认实例模式是每个会话，默认并发模式是单个
这意味着对于WCF服务，直到您更改服务只有一个实例上下文，一次允许在实例上下文中最多有一个线程处理消息。其他希望使用相同实例上下文的线程必须阻塞，直到原始线程退出实例上下文
因此，在您为此进行代码更改并希望它发生之前，您所担心的内容似乎是不可能的。
有关详细信息，请参阅：MSDN
您应该更改您的服务，以便他们不依赖于HttpContext.Current。优选地，完全不依赖于HttpContext。
HttpContext.Current是UI线程的服务器端等价物。只是不要在不需要依赖它的代码上使用它。