我知道这里有一个非常相似的问题，但我希望能得到更好的解释。如果 HttpContext 真的在幕后使用 HttpRuntime.Cache，为什么我会使用 HttpContext.Cache 而不是 HttpRuntime.Cache？
在使用 ASP.NET 模拟 Windows 服务来运行计划作业的文章中， Omar 使用 HttpContext 来存储他的缓存项，但是当 Jeff Atwood在这里实现它时，他选择使用 HttpRuntime。显然，在这种特殊情况下，这是有道理的，因为您不必执行 Web 请求即可将缓存项添加回 HttpContext。
但是，我正在寻找一些关于何时使用一种与另一种的良好指示。
最后它确实是同一个缓存，只是HttpContext.Current有时可以为空（当不在 web 上下文中，或者在 web 上下文中但尚未构建时）。您始终可以安全使用HttpRuntime.Cache.
当您在常规网页中时，您可以安全地使用HttpContext.Cache或仅使用Cache该页面的属性。
如果您正在执行不在页面中的操作，您通常需要使用HttpRuntime.Cache来安全地访问它。
在某些情况下，您可以知道是否存在 http 上下文，例如，如果您从网页启动单独的线程，则该线程没有 http 上下文。在其他情况下，有时您可能会有一个 http 上下文，例如在 中的Application_Start方法中global.asax，因为应用程序可能并不总是因为有请求而启动。
我也发现它具有误导性，尽管我们都知道它只是在HttpRuntime.Cache内部返回。我猜想，HttpRuntime 也是公开缓存的一种不好的选择。
大家都说Session会话级缓存是怎么回事，而我们说的缓存是应用级的。我更愿意Application.Cache使用我们今天使用的缓存，并HttpContext.Cache引用所谓的HttpContext.Items.
至于回答你的问题，我认为我们都应该坚持使用 HttpRuntime.Cache 使我们的代码更清晰，即使我们确实有各种方法可以访问它。当您认真计划使用它时，您最好包装自己的 API 并在内部调用HttpRuntime's或任何其他缓存实现（EntLib、Velocity 等）。