我知道有一个非常相似的问题here，但我希望得到更好的解释。如果 HttpContext 真的在幕后使用 HttpRuntime.Cache，我为什么还要使用 HttpContext.Cache 而不是 HttpRuntime.Cache？
在Simulate a Windows Service using ASP.NET to run scheduled jobs 文章中，Omar 使用 HttpContext 来存储他的缓存项，但是当 Jeff Atwood 实现它时here 他选择使用 HttpRuntime。显然，在这种特殊情况下，这是有道理的，因为您无需执行 Web 请求即可将缓存项添加回 HttpContext。
但是，我正在寻找一些关于何时使用一种与另一种的良好指示。
【问题讨论】：
标签： asp.net caching httpcontext httpruntime.cache
最后确实是同一个缓存，只是 HttpContext.Current 有时可以为空（当不在 web 上下文中，或者在 web 上下文中但尚未构造时）。始终使用HttpRuntime.Cache 是安全的。
【讨论】：
当您在常规网页中时，可以安全地使用 HttpContext.Cache 或仅使用页面的 Cache 属性。
如果您正在执行不在页面中的操作，您通常需要使用 HttpRuntime.Cache 来安全地访问它。
在某些情况下，您可以知道是否存在 http 上下文，例如，如果您从网页启动单独的线程，则该线程没有 http 上下文。在其他情况下，有时您可能会有一个 http 上下文，例如在 global.asax 中的 Application_Start 方法中，因为应用程序可能并不总是因为有请求而启动。
【讨论】：
虽然我们都知道它只是在内部返回 HttpRuntime.Cache，但我也发现它具有误导性。此外，我猜 HttpRuntime 是公开缓存的一个糟糕选择。
每个人都说Session 是会话级缓存，而我们所说的缓存是应用程序级的。我更喜欢Application.Cache 作为我们今天使用的缓存，HttpContext.Cache 指代所谓的HttpContext.Items。
至于回答你的问题，我认为我们都应该坚持使用 HttpRuntime.Cache 以使我们的代码更清晰，即使我们确实有各种方法可以访问它。当您认真计划使用它时，您最好封装自己的 API 并在内部调用 HttpRuntime's 或任何其他缓存实现（EntLib、Velocity 等...）。
【讨论】：