有几件事情需要考虑，有多种方法可以解决。首先，规格

我们要完成什么？

理想情况下，修改后的资源将在首次请求时无条件获取，然后从本地缓存中检索，直到它到期且没有后续服务器交互。

观察到的缓存行为

跟踪不同的排列可能会有些混乱，因此我创建了下表。这些观察结果是通过从Chrome向IIS发出请求并在开发人员控制台中观察响应/行为而生成的。

在所有情况下，新的URL都将产生HTTP200。重要的是 后续 请求会发生什么。

+---------------------+--------------------+-------------------------+
|        Type         |   Cache Headers    |     Observed Result     |
+---------------------+--------------------+-------------------------+
| Static filename     | Expiration +1 Year | Taken from cache        |
| Static filename     | Expire immediately | Never caches            |
| Static filename     | None               | HTTP 304 (not modified) |
|                     |                    |                         |
| Static query string | Expiration +1 Year | HTTP 304 (not modified) |
| Static query string | Expire immediately | HTTP 304 (not modified) |
| Static query string | None               | HTTP 304 (not modified) |
|                     |                    |                         |
| Random query string | Expiration +1 Year | Never caches            |
| Random query string | Expire immediately | Never caches            |
| Random query string | None               | Never caches            |
+---------------------+--------------------+-------------------------+

但是
，请记住，浏览器和Web服务器并不总是按照我们期望的方式运行。一个著名的例子：2012年，移动Safari开始缓存POST请求。开发人员不满意。

请求参数

ASP.Net MVC Razor语法中的示例，但几乎适用于所有服务器处理语言。

…由于某些应用程序传统上使用带有查询URL的GETs和HEADs（在rel_path部分中包含“？”的URL）来执行具有明显副作用的操作，因此，除非服务器提供了响应，否则缓存不得将对此类URI的响应视为新鲜的明确的到期时间。这特别意味着，不应从缓存中获取来自HTTP / 1.0服务器对此类URI的响应。

将随机参数添加到HTML中包含的CSS URL的末尾将强制执行新请求，并且服务器应使用HTTP200响应（而不是304，即使尚未修改）。

<link href="normalfile.css?random=@Environment.TickCount" />

当然，如果我们对 每个 请求随机分配查询字符串，这将完全破坏缓存。 这对于生产应用来说是很少/永远不需要的。

如果仅维护一些URL，则可以手动修改它们以包含内部版本号或日期：

@{
    var assembly = Assembly.GetEntryAssembly();
    var name = assembly.GetName();
    var version = name.Version;
}

<link href="normalfile.css?build=@version.MinorRevision" />

这将在用户代理第一次遇到URL时引起一个新请求，但是后续请求将大部分返回304。这仍然会导致发出请求，但至少不会提供整个文件。

路径修改

更好的解决方案是创建一条新路径。只需一点努力，即可自动完成此过程，以使用版本号（或其他一致的标识符）重写路径。

该答案显示了用于非Microsoft平台的一些简单而优雅的选项。

微软开发人员可以使用HTTP模块来拦截给定文件类型的所有请求，或者可以利用MVC路由/控制器组合来提供正确的文件（我还没有看到这样做，但是我相信这是可行的）。

当然，最简单的方法（不一定是最快或最好的方法）是在每个发行版中重命名有问题的文件，并在link标记中引用更新的路径。

TLDR

• 更改文件名或查询字符串
• 使用每个版本仅发生一次的更改
• 文件重命名比更改查询字符串更可取
• 始终设置HTTP标头以最大限度地利用缓存的好处