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

I found 本文 https://www.quickdevnotes.com/better-approach-to-use-httpcontext-outside-a-controller-in-net-core-2-1/在尝试解决需要非控制器中的一些标头的问题时。
我对这种方法非常怀疑，而且作者没有回应。我主要关心的是全局静态的方法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这个静态类的上下文，这正是我所期望的（而且它确实没用）。
然而，令我困惑的是实际行为。我正在调试在该行放置断点的片段var result = ...。我首先发送一个请求number= 1 将休眠一段时间，然后我发送具有不同值的第二个请求number。我跳过为第一个请求放置的断点并等待第一个请求（使用number= 1) 停在那里。然后我检查什么GetDisplayUrl()返回 - 它返回一个路径/1（这确实是该请求已休眠 10 秒的路径）。我希望它结束​​于/2作为静态场IHttpContextAccessor静态类的AppContext已被第二个请求重写ConfigureServices() method.
我相信我错过了一些重要的东西，如果您也提供一些我（和其他困惑的人）可以用来填补空白的资源，我会很高兴。
您能否给我一些关于使用该方法的更多见解？可测试性是否会受到影响（因为我在应用程序中的任何地方都使用静态类）以及以何种方式受到影响？

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

HttpContext本身是有范围的，但这不是这里设置的。所以，只要您能够访问IHttpContextAccessor，从技术上讲，您可以访问HttpContext，尽管它可能为空，具体取决于您尝试执行此操作的位置（即在请求管道之外）。

然而，这种做法太糟糕了，一点都不好笑。对于好的代码来说，应该在很大程度上避免静态。它们不可测试，并且用于隐藏依赖项，使您的代码更难理解且更脆弱。

我见过有些人做了类似的事情，但那是为了让HttpContext本身看起来就好像它是静态的，其目标只是支持假定静态的遗留代码HttpContext。该解决方案对此没有帮助，因为无论哪种方式您都必须更改遗留代码。因此，它完全没有用。

如果您需要访问HttpContext在它本质上存在的地方（例如控制器、页面和视图）之外，然后简单地注入IHttpContextAccessor那里，然后直接使用它。这整个AppContext这东西就是个笑话，应该死在火里。