将哈希附加到 js 文件名 vs Cache-Control: no-store答案

【问题标题】：Appending hash to js filenames vs Cache-Control: no-store将哈希附加到 js 文件名 vs Cache-Control: no-store
【发布时间】：2021-10-31 21:50:51
【问题描述】：

我正在阅读这个answer，关于如何将资源（例如 JS 或 CSS 文件）的哈希附加到文件名，以便您的浏览器仅在更改时才下载它，否则使用缓存版本。

为什么要在 HTTP 标头 Cache-Control: no-cache 上使用它？

在文件名中使用哈希意味着您需要确保永远不会缓存包含 <script src="myscript.someHash.js"></script> 标记的 HTML。

为什么不允许使用 no-cache 缓存 HTML（和所有其他资源）？

【问题讨论】：

@KevinChristopherHenry 是的模式 1. 它不涉及确保包含指向 JS 和 CSS 文件的链接的 HTML 永远不会被缓存吗？是关于利弊吗，优点是模式 1 不涉及到服务器的明确往返，但它涉及每次从服务器获取相同的 HTML？
@KevinChristopherHenry 模式 1 仅在每次都从服务器获取 HTML 时才有效。您不能使用 HTML 的缓存副本，否则它可能包含 js 文件名的旧哈希。而对于模式 2，您无需下载整个 HTML，而是在大多数情况下获得未修改的 304。
不，你误会了什么。您对模式 1 中的 HTML 文件执行与对模式 2 中的所有文件执行完全相同的操作，发送一个条件请求。如果服务器以304 响应，那么您就知道它没有更改，并且根据定义，它引用的文件名并不旧。
在任何情况下都将尝试重新验证，所有must-revalidate 影响的是发生错误时发生的情况（例如，服务器无法访问）。如果设置了must-revalidate，客户端将显示错误而不是提供陈旧的页面。这通常不是您想要的，这就是为什么标准建议将其使用限制在“未能验证对表示的请求可能导致错误操作”的情况。
我不太确定你在说什么。 504 位隐含在“必须”中；如果标准说MUST，而你不能，那么这是一个错误。至于“几乎相同”，no-cache 和no-cache, must-revalidate 将在 99% 的时间（或者无论您的服务器的正常运行时间如何）的行为方式相同。在这两种情况下，都会尝试重新验证。

标签： http caching browser-cache http-caching

【解决方案1】：

这里讨论的是两种不同的缓存页面方式，同时仍能确保正确性。 This article 很好地描述了它们，所以我将使用它的术语：模式 1 在 HTML 页面上使用 no-cache，但为每个版本的静态资产创建唯一的文件名，并允许它们将被永久缓存。 模式 2 只是使用 no-cache 来处理所有事情。

它们都有效。从性能的角度来看，模式 1 将非常出色，因为它的一些页面只有no-cache。唯一的缺点是构建工作流程更加复杂，因为您需要生成唯一的文件名并确保您的 HTML 页面正确链接到它们。幸运的是，许多框架都支持这种工作流程。

您的主要担忧似乎是“您需要确保永远不会缓存包含 [静态链接] 的 HTML”。但它仍然可以被缓存，只是每次使用时都需要重新验证。但模式 2 中的每个文件都是如此，因此它不是相对劣势。

【讨论】：