通过静态类访问 HttpContext 可以“正确”处理不同的请求

Question

我在尝试解决需要非控制器中的一些标头的问题时发现了这篇文章。
我对这种方法持怀疑态度，作者没有回应。我主要关心的是使用 global static 的方法HttpContext。我在想它不应该处理两个请求。这种情况的一个例子如下（连同我提到的文章中介绍的方法）：

public static class AppContext
{
    public static IHttpContextAccessor HttpContextAccessor { get; set; }
    public static void Configure(IHttpContextAccessor accessor)
    {
        HttpContextAccessor = accessor;
    }
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env,
    IHttpContextAccessor contextAccessor)
{
    AppContext.Configure(contextAccessor);
    ...
}

[Route("api/[controller]")]
[ApiController]
public class ExampleController : ControllerBase
{
    [HttpGet("{number}")]
    public IActionResult Example(int number)
    {
        if (number == 1)
        {
            Thread.Sleep(10000);
        }

        var result = AppContext.HttpContextAccessor.HttpContext.Request.GetDisplayUrl();

        return Ok(result + " " + number);
    }
}

想提一下作者为这个静态类使用名称App Context ，这正是我所期望的（那时它确实没用）。
然而，让我感到困惑的是实际行为。我正在调试在带有var result = .... 我首先发送一个带有number= 1的请求，该请求将休眠一段时间，然后我发送具有不同值的第二个请求number。我跳过第一个请求的断点并等待第一个请求（number= 1）在那里停止。然后我检查什么GetDisplayUrl()返回 - 它返回一个路径/1（这确实是这个请求的路径，它已经休眠了 10 秒）。我希望它以静态类/2的静态字段结束IHttpContextAccessorAppContext已被ConfigureServices()方法中的第二个请求重写。
我相信我遗漏了一些重要的东西，如果你还提供了一些我（和其他人感到困惑）可以用来填补空白的资源，我会很高兴。
您能否也给我一些有关使用该方法的更多见解？可测试性是否受到影响（因为我在应用程序的任何地方都使用静态类）以及以什么方式？

Answer 1

这里发生了一些事情。从技术上讲，这行得通，因为IHttpContextAccessor它是单例。因此，将它保留在静态 ivar 上在技术上没有任何问题。无论哪种方式，它都会持续应用程序的生命周期。

HttpContext, 本身是有作用域的，但这不是这里设置的内容。因此，只要您有权访问IHttpContextAccessor，您就可以在技术上访问HttpContext，尽管它可能为空，具体取决于您尝试执行的位置（即在请求管道之外）。

然而，这是一种糟糕的做法，甚至都不好笑。对于好的代码，应该在很大程度上避免静态。它们不可测试，它们用于隐藏依赖关系，使您的代码更难理解和更脆弱。

我见过一些人做类似的事情，但那是为了让HttpContext自己看起来好像是静态的，目的只是支持假设静态的遗留代码HttpContext。此解决方案在那里没有帮助，因为您必须以任何方式更改遗留代码。因此，它完全没有用。

如果你需要访问HttpContext它本质上存在的地方之外的地方，比如控制器、页面和视图，那么只需注入IHttpContextAccessor那里，然后直接使用它。这整件事AppContext都是一个笑话，应该死在火里。