问在HttpContext.Current中使用WebApi是危险的，因为异步

EN

我的问题与此有关：WebApi equivalent for HttpContext.Items with Dependency Injection。

我们希望使用HttpContext.Current在WebApi区域中使用Ninject注入一个类。

我担心的是，这可能是非常危险的，就像WebApi (一切？)就是异步。

如果我在这些问题上错了，请纠正我，这就是我到目前为止所调查的：

1. HttpContext.Current通过线程获取当前上下文(我直接查看了实现)。

1. 在异步任务中使用HttpContext.Current是不可能的，因为它可以在另一个线程上运行。

1. WebApi使用IHttpController和方法Task<HttpResponseMessage> ExecuteAsync =>每个请求都是异步=>，您不能在操作方法中使用HttpContext.Current。这甚至可能发生，更多的请求是在同一个线程上执行的。

1. 为了创建带有注入构造函数的控制器，IHttpControllerActivator与同步方法IHttpController Create一起使用。这就是ninject创建Controller及其所有依赖项的地方。

• 如果我在所有这4点上都是正确的，那么在一个动作方法或下面的任何一层中使用HttpContext.Current是非常危险的，并且可能会有意想不到的结果。我在StackOverflow上看到了很多被接受的答案，这些都说明了这一点。在我看来，这可以工作一段时间，但在负荷下会失败。

• 但是，当使用DI创建Controller及其依赖项时，它是可以的，因为它运行在一个分离的线程上。--我可以从构造函数中的HttpContext中获得一个值，它将是安全的？。我想知道每个Controller是否都是在单个线程上为每个请求创建的，因为这可能会在重负载下造成问题，因为IIS中的所有线程都可以被消耗掉。

为了解释我为什么要注入HttpContext内容：

• 一种解决方案是在控制器操作方法中获取请求，并以param的形式传递所需的所有层值，直到它在代码中的某个位置使用为止。
• 我们想要的解决方案:所有层之间都不受此影响，我们可以在代码中的某个地方使用注入的请求(例如，在一些依赖于URL的ConfigurationProvider中)

如果我完全错了，或者我的建议是正确的，请给我你的意见，因为这个主题似乎很复杂。