这不像每个请求一样简单。我们有一个网站有一段时间稳定的CSS。
现在我们需要对CSS进行一些主要的更新;但是，缓存CSS的浏览器将不会收到新的CSS几天导致渲染问题。
有没有办法强制刷新CSS或者我们更好只是选择版本特定的CSS URL？
解决方法
我们想要完成什么？
理想情况下，修改的资源将在第一次被请求时被无条件地获取，然后从本地缓存检索，直到它到期，没有后续的服务器交互。
观察缓存行为
跟踪不同的排列可能有点混乱，所以我创建了下表。这些观察结果是通过从Chrome向IIS发出请求并在开发人员控制台中观察响应/行为而生成的。
在所有情况下，新的URL将导致HTTP 200.重要的是随后的请求会发生什么。
+---------------------+--------------------+-------------------------+ | 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服务器并不总是符合我们的预期。一个着名的例子：in 2012 mobile Safari began caching POST requests.开发人员不高兴。
查询字符串
ASP.Net MVC Razor语法中的示例，但适用于几乎任何服务器处理语言。
…since some applications have traditionally used GETs and HEADs with
query URLs (those containing a “?” in the rel_path part) to perform
operations with significant side effects,caches MUST NOT treat
responses to such URIs as fresh unless the server provides an explicit
expiration time. This specifically means that responses from HTTP/1.0
servers for such URIs SHOULD NOT be taken from a cache.
将随机参数附加到HTML中包含的CSS网址末尾将会强制发送一个新请求，服务器应该使用HTTP 200(而不是304，即使尚未回应)
改性)。
<link href="normalfile.css?random=@Environment.TickCount" />
当然，如果我们用每个请求随机化查询字符串，这将完全失去缓存。这对于生产应用来说很少/不期望。
如果您只维护几个网址，则可以手动修改它们以包含内部版本号或日期：
@{
var assembly = Assembly.GetEntryAssembly();
var name = assembly.GetName();
var version = name.Version;
}
<link href="normalfile.css?build=@version.MinorRevision" />
这将在第一次用户代理遇到URL时引起新的请求，但后续请求将主要返回304。这仍然会导致发出请求，但至少不会提供整个文件。
路径修改
一个更好的解决方案是创建一个新的路径。通过少许努力，该过程可以被自动化以用版本号(或一些其他一致的标识符)重写路径。
This answer为非Microsoft平台显示了一些简单而优雅的选项。
Microsoft开发人员可以使用HTTP模块，拦截给定文件类型的所有请求，或者可能利用MVC路由/控制器组合来提供正确的文件(我没有看到这样做，但我相信它是可行的)。
当然，最简单的(不一定是最快或最好的)方法是仅仅重命名每个版本的相关文件，并在链接标签中引用更新的路径。
TLDR
>更改文件名或查询字符串>使用每次发布只发生一次的更改>文件重命名优于查询字符串更改>始终设置HTTP标头以最大化缓存的好处
