有几件事情需要考虑，有多种方法可以解决。首先，规格
我们要完成什么？
理想情况下，修改后的资源将在首次请求时无条件获取，然后从本地缓存中检索，直到它到期且没有后续服务器交互。
观察到的缓存行为
跟踪不同的排列可能会有些混乱，因此我创建了下表。这些观察结果是通过从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标头以最大限度地利用缓存的好处
