这里的所有答案似乎都表明在命名方案中存在某种版本控制，但这也有其缺点。

浏览器应该通过读取web服务器的响应，特别是HTTP报头来清楚地知道什么该缓存，什么不该缓存——这个资源的有效期是多长?自上次检索该资源以来，该资源是否已更新?等。

如果事情配置“正确”，只是更新你的应用程序的文件应该(在某些时候)刷新浏览器的缓存。例如，你可以配置你的web服务器，告诉浏览器永远不缓存文件(这是一个坏主意)。

更深入的解释在Web缓存的工作原理中。

只需使用服务器端代码添加文件的日期…这样，它将被缓存，只有当文件更改时才会重新加载。

在ASP。NET:

<link rel="stylesheet" href="~/css/custom.css?d=@(System.Text.RegularExpressions.Regex.Replace(File.GetLastWriteTime(Server.MapPath("~/css/custom.css")).ToString(),"[^0-9]", ""))" />

<script type="text/javascript" src="~/js/custom.js?d=@(System.Text.RegularExpressions.Regex.Replace(File.GetLastWriteTime(Server.MapPath("~/js/custom.js")).ToString(),"[^0-9]", ""))"></script>

这可以简化为:

<script src="<%= Page.ResolveClientUrlUnique("~/js/custom.js") %>" type="text/javascript"></script>

通过在项目中添加扩展方法来扩展Page:

public static class Extension_Methods
{
    public static string ResolveClientUrlUnique(this System.Web.UI.Page oPg, string sRelPath)
    {
        string sFilePath = oPg.Server.MapPath(sRelPath);
        string sLastDate = System.IO.File.GetLastWriteTime(sFilePath).ToString();
        string sDateHashed = System.Text.RegularExpressions.Regex.Replace(sLastDate, "[^0-9]", "");

        return oPg.ResolveClientUrl(sRelPath) + "?d=" + sDateHashed;
    }
}

在Laravel (PHP)中，我们可以以以下清晰而优雅的方式(使用文件修改时间戳)做到这一点:

<script src="{{ asset('/js/your.js?v='.filemtime('js/your.js')) }}"></script>

CSS也是如此

<link rel="stylesheet" href="{{asset('css/your.css?v='.filemtime('css/your.css'))}}">

示例HTML输出(filemtime返回时间作为Unix时间戳)

<link rel="stylesheet" href="assets/css/your.css?v=1577772366">

对于一个2008年左右的网站来说，这30个左右的答案是很好的建议。然而，当涉及到现代的单页应用程序(SPA)时，可能是时候重新考虑一些基本假设了……特别是web服务器只提供文件的单个最新版本是理想的想法。

假设您是一个用户，浏览器中加载了SPA的M版本:

CD管道将应用程序的新版本N部署到服务器上 您在SPA中导航，它向服务器发送一个XMLHttpRequest (XHR)以获取/some.template

(您的浏览器没有刷新页面，所以您仍然在运行版本M)

服务器返回/some的内容。template -你想让它返回模板的版本M还是N ?

如果格式为/some。模板在版本M和N之间发生了变化(或者文件被重命名了等等)，你可能不希望将版本N的模板发送到运行旧版本M解析器的浏览器。†

Web应用程序在满足两个条件时遇到这个问题:

在初始页面加载后的一段时间内异步请求资源 应用程序逻辑假设有关资源内容的事情(在将来的版本中可能会改变)

一旦你的应用程序需要并行提供多个版本，解决缓存和“重新加载”变得微不足道:

将所有site文件安装到versioned目录:/v<release_tag_1>/…files…，/v<release_tag_2>/…files… 设置HTTP头，让浏览器永远缓存文件

(或者更好的是，把所有东西都放在CDN中)

更新所有<script>和<link>标签等，以指向某个版本目录中的该文件

最后一步听起来很棘手，因为它可能需要为服务器端或客户端代码中的每个URL调用URL构建器。或者您可以聪明地使用<base>标记并在一个地方更改当前版本。

†解决这个问题的一种方法是在新版本发布时强制浏览器重新加载所有内容。但是为了让任何正在进行的操作完成，至少并行支持两个版本:v-current和v-previous可能仍然是最简单的。

假设你有一个文件可用:

/styles/screen.css

你可以在URI上附加一个包含版本信息的查询参数，例如:

/styles/screen.css?v=1234

或者你可以在前面加上版本信息，例如:

/v/1234/styles/screen.css

恕我直言，第二种方法更适合CSS文件，因为它们可以使用相对url引用图像，这意味着如果你指定一个背景图像，像这样:

body {
    background-image: url('images/happy.gif');
}

它的URL实际上是:

/v/1234/styles/images/happy.gif

这意味着如果您更新了使用的版本号，服务器将将其视为新资源，而不是使用缓存的版本。如果您的版本号基于Subversion、CVS等版本，这意味着CSS文件中引用的图像的更改将被注意到。第一种方案并不能保证这一点，即URL images/happy.gif相对于/styles/screen.css?V =1235是/styles/images/happy.gif，它不包含任何版本信息。

I have implemented a caching solution using this technique with Java servlets and simply handle requests to /v/* with a servlet that delegates to the underlying resource (i.e. /styles/screen.css). In development mode I set caching headers that tell the client to always check the freshness of the resource with the server (this typically results in a 304 if you delegate to Tomcat's DefaultServlet and the .css, .js, etc. file hasn't changed) while in deployment mode I set headers that say "cache forever".

你可以把?foo=1234放在CSS / JavaScript导入的末尾，把1234改成你喜欢的任何值。看一下Stack Overflow HTML源代码的例子。

这里的意思是?无论如何，参数都会在请求中被丢弃/忽略，您可以在推出新版本时更改这个数字。

注意:关于这究竟如何影响缓存存在一些争论。我认为它的一般要点是GET请求，无论是否带参数都应该是可缓存的，因此上面的解决方案应该是有效的。

然而，这取决于web服务器和用户使用的浏览器，因为它可以直接要求一个新的版本。