管理缓存行为

Firebase Hosting 使用遍布全球的强大 CDN，可最大限度提高您的网站的速度。

所请求的任何静态内容都会自动缓存在 CDN 中。如果您重新部署网站的内容，Firebase Hosting 会在下次请求之前自动清除整个 CDN 中所有缓存的内容。

但是，由于 Cloud Functions 和 Cloud Run 服务会动态生成内容，因此给定网址的内容可能会因用户输入或用户身份等而异。考虑到这一点，默认情况下，后端代码处理的请求不会缓存在 CDN 中。

但是，您可以为动态内容配置缓存行为。例如，如果某个函数只是定期生成新内容，您可以通过将生成的内容至少缓存一小段时间来加快您应用的速度。

同样，您可以配置缓存行为以降低函数执行费用，因为内容是通过 CDN 传送的，而不是通过触发的函数传送的。如需详细了解如何优化函数的执行和服务，请参阅 Cloud Functions 和 Cloud Run 文档。

例外情况是返回 404 错误的请求。CDN 会将服务的 404 响应缓存到不存在的网址长达 10 分钟，以便针对该网址的后续请求会从 CDN 中传送出来。如果您更改服务，以使内容现在存在于此网址，CDN 会继续传送所有缓存的 404 响应长达 10 分钟（最多），然后按照正常方式从该网址传送内容。

如果 404 响应已包含由 Cloud Functions 或 Cloud Run 服务设置的缓存标头，则它们会替换默认值 10 分钟，并完全确定 CDN 的缓存行为。

如需详细了解缓存行为，请参阅 Google 的 Web 开发者文档。

设置 Cache-Control

用于管理动态内容缓存的主要工具是 Cache-Control 标头。通过配置此标头，您可以告知浏览器和 CDN 可将您的内容缓存多长时间。在函数中设置 Cache-Control 的方式如下所示：

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

在此示例标头中，以下指令会执行三项操作：

• public - 将缓存标记为 public。这意味着浏览器和中间服务器（即用于 Firebase Hosting 的 CDN）都可以缓存内容。

• max-age - 告知浏览器和 CDN 可以缓存内容的秒数。当达到设置的时间时，浏览器和 CDN 必须与源服务器重新验证内容。在示例标头中，我们允许浏览器和 CDN 将内容缓存五分钟（有关 CDN 缓存的特定控制措施，请参阅下文的 s-maxage）。

• s-maxage - 仅替换 CDN 缓存的 max-age 指令；告知 CDN 可以缓存内容的秒数。当达到设置的时间时，CDN 必须与源服务器重新验证内容。在示例标头中，我们仅替换 CDN 的 max-age 设置，并允许 CDN 将内容缓存十分钟。

对于 max-age 和 s-maxage，请将其值设置为允许用户收到过期内容的最长时间。如果页面每几秒更改一次，请使用较小的时间值。但是，其他类型的内容可以安全地缓存数小时、数天甚至数月。

如果您想完全阻止缓存（例如始终提供最新版本的静态内容），可以在 firebase.json 中通过 headers 设置来进行配置：

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

您可以参阅 Mozilla 开发者网络以及 Google 的 Web 开发者文档，以详细了解 Cache-Control 标头。

何时提供缓存的内容？

浏览器和 CDN 会根据以下各项缓存您的内容：

• 主机名
• 路径
• 查询字符串
• Vary 标头中指定的请求标头的内容

Vary 标头

Vary 标头决定了应使用哪些请求标头提供适当的响应（缓存内容是否有效，或是否应与源服务器重新验证该内容）。

Firebase Hosting 可自动针对常见情况为您的响应设置适当的 Vary 标头。大多数情况下，您无需担心 Vary 标头。不过，在某些高级使用场景中，您可能需要其他标头来影响缓存。在这种情况下，您可以在响应中设置 Vary 标头。例如：

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

在此示例中，Vary 标头的值为：

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

如果采用这些设置，两个具有不同 X-My-Custom-Header 标头的相同请求会分别被缓存。请注意，当请求获取动态内容时，Hosting 默认会将 Cookie 和 Authorization 添加到 Vary 标头中。这样可以确保您使用的任何会话或 Cookie 授权标头均为缓存键的一部分，从而防止意外泄露内容。

另外还需注意以下事项：

• 只能缓存 GET 和 HEAD 请求。使用其他方法的 HTTPS 请求永远不会被缓存。

• 向 Vary 标头添加设置时要小心。您添加的设置越多，CDN 提供缓存内容的可能性越小。 另请注意，Vary 基于请求标头，而不是响应标头。

使用 Cookie

将 Firebase Hosting 与 Cloud Functions 或 Cloud Run 搭配使用时，Cookie 通常会从传入的请求中剥离出来。要实现高效的 CDN 缓存行为，就必须如此。只有特别指定的 __session Cookie 可以传入应用执行过程。

__session Cookie（如果存在）会自动成为缓存键的一部分，也就是说，使用不同 Cookie 的两个用户绝不会收到对方的已缓存响应。仅当您的应用需要根据用户授权提供不同的内容时，才应使用 __session Cookie。