我已经阅读了很多关于这个问题的相关文章,还有关于HTTP缓存的非常好的文章：
但我仍不清楚：
为什么不发送足够的ETag标头来使特定资源的浏览器缓存无效？为什么每个人都建议实际更改资源的URL /文件名以强制浏览器重新下载文件？如果浏览器已经使用特定的ETag缓存了文件并且在服务器上修改了ETag,那还不够吗？
最佳答案 我发现以下页面有用：
> https://jakearchibald.com/2016/caching-best-practices/
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
来自MDN的ETag页面的这一行分享了关键点(重点补充)：
If a user visits a given URL again (that has an ETag set), and it is stale, that is too old to be considered usable, the client will send the value of its ETag along in an If-None-Match header field…
一旦客户变得“陈旧”,客户将使用ETag重新验证资源.但什么构成“陈旧”？
这是Cache-Control标头派上用场的地方.可以通过响应发送Cache-Control标头,让客户端知道客户端可以缓存项目多长时间,直到它被认为是陈旧的.例如,Cache-Control：no-cache表示该资源应立即被视为过时.有关可用缓存控制值的更多信息,请参见MDN Cache-Control page.
当浏览器尝试处理被认为是陈旧的缓存资源的请求时,它将首先向服务器发送重新验证请求,其中资源的最后一个ETag值通过If-None-Match请求头包含,如MDN’s ETag page所述.也可以使用作为If-Modified-Since请求标头发送的Last-Modified响应标头作为辅助选项.
如果服务器确定客户端的ETag值(在If-None-Match请求头中)是最新的,那么它将使用304(未修改)HTTP状态代码和空体响应,表明客户端可以使用缓存条目.否则,服务器将使用200 HTTP状态代码和新响应正文进行响应.
其他资源：
> Difference between no-cache and must-revalidate
> What’s default value of cache-control?
直接回答您的问题：
>为什么不发送足够的ETag标头来使特定资源的浏览器缓存无效？ – 因为在高速缓存的条目被认为是陈旧的之前,ETag标头未经过验证,例如通过Cache-Control响应标头中设置的过期日期.
>为什么每个人都建议实际更改资源的URL /文件名以强制浏览器重新下载文件？ – 更改URL /文件名或添加查询字符串将强制客户端避免使用缓存.这很简单,几乎可以保证缓存破坏.这并不意味着它是必要的,但它在浏览器行为不一致的情况下往往是安全的.
>如果浏览器已经使用特定的ETag缓存了文件并且在服务器上修改了ETag,那还不够吗？ – 从技术上讲,只要包含适当的Cache-Control标头(包括Pragma和Expires标头),它就足够了.有关详细信息,请参阅How to control web page caching, across all browsers?.
