A 多语言网站 需要在保证速度的前提下，将正确的翻译内容传递给正确的访客。这正是缓存多语言网站变得至关重要的原因，它可以帮助翻译页面更快加载，同时减少对服务器的重复请求。然而，缓存多个语言版本可能会带来一些挑战，例如翻译内容过时、语言内容错误，以及搜索引擎爬虫获得不一致的结果。
在本指南中，我们将探讨最常见的多语言缓存问题，并解释 Cloudflare 和 Varnish 如何处理翻译内容。继续阅读，以选择正确的缓存策略，防止跨语言缓存命中，并为您的多语言网站构建可靠的设置。.
要点：使用 Cloudflare & Varnish 实现多语言网站缓存
独立语言版本
使用特定语言的 URL 或缓存键，确保每个翻译版本被单独存储和提供。这有助于防止用户收到错误语言的内容。.
防止缓存冲突
Varnish 和 Cloudflare 必须考虑来自 URL、标头或 Cookie 的语言信息。正确的配置可防止跨语言缓存命中，并确保访问者收到正确的翻译。.
保持翻译内容新鲜
设置适当的缓存 TTL，并在翻译更新时清除受影响的缓存。这可以防止过时内容继续对访客可见。.
为什么多语言缓存很重要？
多语言网站可能会为同一页面缓存多个版本，因为每种语言可能包含不同的内容和 URL。缓存这些翻译版本可以让网站复用已有的响应，而不必为每个请求重复处理相同的内容。这可以减少对源服务器的请求、提升页面加载速度，并为访客提供更快速的体验。.
然而，多语言缓存需要将每种语言版本妥善分离。如果缓存系统不区分语言变体，请求法语页面的访客可能会收到缓存的英语版本。同样，当翻译更新时，旧的缓存响应可能会继续显示，直到过期或被失效。.
缓存也在搜索引擎爬虫访问多语言页面时发挥作用。每个语言URL应始终返回其对应的翻译内容，以便搜索引擎能够正确理解并索引本地化版本。因此，可靠的缓存设置应与SEO信号协同工作，例如 hreflang、canonical URL 以及特定语言的元数据。
如何构建多语言网站缓存策略
良好的多语言缓存策略可确保访客始终获得正确的语言版本，同时保持页面快速并减少服务器请求。第一步是确定您的网站如何识别每种语言，以及缓存系统如何使用该信息。.
URL 和子域名路由
语言专属 URL 是实现多语言缓存可预测性的最简单方法之一。每种语言都有自己的 URL，因此缓存可以分别存储和提供每个版本。例如，example.com/fr/ 可以代表法语版本，而 example.com/de/ 则代表德语版本。.
特定语言的子域名工作原理类似。网站可能会使用 fr.example.com 作为法语版本，de.example.com 作为德语版本。由于语言直接包含在 URL 中，访问者和缓存系统可以轻松识别应提供哪个版本。常见的 URL 结构包括：
- example.com/fr/
- example.com/de/
- fr.example.com
- de.example.com
基于标头的语言检测
网站还可以通过 HTTP 标头（尤其是浏览器发送的 Accept-Language 标头）来确定访客的首选语言。例如，配置为法语的浏览器可能会发送 Accept-Language: fr，从而让服务器自动选择法语版本。.
然而，基于标头的检测需要谨慎配置缓存。如果缓存仅考虑页面 URL 而忽略语言标头，它可能会存储一种语言版本并将其返回给具有不同语言偏好的访客。因此，缓存键或 Vary 行为必须考虑相关的语言信息。例如：
- Accept-Language: en
- Accept-Language: fr
- Accept-Language: de
基于 Cookie 的语言检测
另一种方法是将访客的语言偏好存储在 cookie 中。一旦访客选择了某种语言，网站就可以保存该选择，并将其用于后续请求。这可以提供更一致的体验，尤其是当访客手动选择语言而不是依赖浏览器设置时。.
挑战在于 Cookie 可能会使缓存变得复杂。如果缓存不根据 语言 Cookie 来区分请求，访问者可能会收到为另一种语言准备的缓存页面。因此，缓存层应配置为在必要时区分或绕过缓存。例如：
- language=en
- language=fr
- language=de
选择缓存策略
最佳的缓存策略取决于您的网站如何处理语言选择。基于 URL 的语言路由通常更容易缓存，因为每种语言都有唯一的 URL。基于请求头和 Cookie 的检测仍然可行，但需要更细致的配置，以确保缓存的响应被正确区分。.
在选择方案之前，请考虑语言数量、访客如何选择语言，以及翻译内容的更新频率。目标是让语言检测和缓存行为协同工作，而不是让缓存层将每个请求都视为同一页面。需要考虑的关键因素：
- 语言特定的URL
- 缓存键配置
- 标头和 Cookie 处理
- 缓存 TTL
- 缓存失效
- 翻译更新频率
- 搜索引擎抓取
Varnish 如何缓存多语言和翻译内容
Varnish Cache 作为访客与源服务器之间的反向代理。当访客请求页面时，Varnish 会检查是否有可用的有效缓存响应。如果找到匹配的响应，它会直接提供缓存内容，而不会将请求发送回源服务器。如果没有合适的响应，Varnish 会将请求转发到源服务器，接收响应，并可以将其存储以供后续请求使用。.
对于多语言网站，Varnish 需要区分应返回不同语言版本的请求。因此，当 Varnish 判断缓存响应是否可以复用时，必须考虑语言信息。这可以防止缓存将不同的翻译视为相同的响应。.
特定语言的缓存键
Varnish 需要一种方法来区分代表不同语言版本的缓存响应。当语言已包含在 URL 中时，每个 URL 自然可以映射到不同的缓存条目。当语言由请求头、Cookie 或其他请求值决定时，Varnish 配置需要将该信息纳入其缓存逻辑。例如，多语言网站可能会使用以下方式区分缓存响应：
- /en/about/ → 英文缓存条目
- /fr/about/ → 法语缓存条目
- Accept-Language: en → 英语变体
- Accept-Language: fr → 法语变体
- 语言 Cookie → 访问者选择的语言
具体实现方式取决于网站如何确定语言。关键要求是，产生不同翻译响应的请求不能解析到同一个缓存对象。.
防止跨语言命中
当 Varnish 将某一语言的缓存响应返回给请求另一语言的访问者时，就会发生跨语言缓存命中。例如，如果两个请求被视为同一个可缓存资源，那么请求法语页面的访问者可能会收到英语响应。.
为降低此风险，Varnish 应仅在语言变体已知且与请求匹配时重用缓存响应。如果无法可靠地确定语言，则应谨慎处理响应，而不是将其存储为共享缓存条目。重要的保护措施包括：
- 避免缓存语言信息不明确的响应
- 一致地处理语言 cookie 和标头
- 测试不同语言请求的缓存命中和未命中
- 启用缓存后验证语言切换
Varnish 缓存失效
缓存失效会移除缓存内容或将其标记为不再有效。当原始内容或其翻译已更新时，这一点非常重要。如果没有失效机制，Varnish 可能会继续提供较旧的缓存版本，直到其配置的 TTL 过期。.
对于多语言网站，失效处理应涵盖所有受影响的语言版本。如果英文页面及其法语翻译被更新，相应的缓存响应应被清除或刷新，以免访客看到过时的内容。常见方法包括：
- 清除特定 URL
- 清除多个语言版本
- 使用缓存 TTL
- 内容更新后自动清除缓存
- 刷新受影响的翻译页面
Cloudflare 如何在边缘缓存多语言内容
Cloudflare 作为访客与源站服务器之间的边缘缓存层发挥作用。当访客请求页面时，Cloudflare 会检查边缘节点是否有可用的缓存版本。如果存在有效响应，可以直接从边缘节点提供，而无需向源站服务器请求该页面。如果没有可用的缓存响应，Cloudflare 会从源站获取内容，并可以缓存该响应以供后续请求使用。.
对于多语言网站，此过程需要考虑所请求的语言。Cloudflare 必须能够区分不同的语言版本，以免将缓存的英文响应提供给请求法文版本的用户。当翻译内容通过不同的 URL、标头或 Cookie 提供时，这使得语言感知缓存配置变得非常重要。.
分离语言版本
当每个语言版本都有不同的 URL 时，Cloudflare 可以分别缓存不同的语言版本。例如，/en/、/fr/ 和 /it/ 可以分别代表英语、法语和意大利语内容。由于语言直接包含在 URL 中，每个版本都可以拥有自己的缓存条目，从而更易于管理和清除单个语言版本。例如：
- example.com/en/products/
- example.com/fr/products/
- example.com/it/products/
Cloudflare 缓存键与语言变体
当不同的语言输入可能产生不同的响应时，Cloudflare 需要区分这些请求。通过基于 URL 的语言路由，这种区分会自然发生，因为每种语言都有自己的 URL。.
当语言由 Accept-Language 请求头或 Cookie 决定时，需要格外注意。如果这些值会影响翻译后的响应，但缓存配置未对其进行处理，那么针对不同语言的请求可能会被视为同一资源。这可能导致向请求某种语言的访客提供另一种语言的内容。.
对于大多数多语言网站而言，基于 URL 的路由更易于管理，因为语言会直接显示在 URL 中。基于请求头和 Cookie 的检测也可以使用，但需要额外配置，以确保不同语言的响应不会被错误地共享。.
缓存 TTL 与清除
缓存 TTL（生存时间）决定了 Cloudflare 在缓存响应过期前保留它的时长。较长的 TTL 可以提升性能，因为内容会缓存更久；而较短的 TTL 则能让更改更快生效。.
对于多语言网站，TTL 应反映内容和翻译的更新频率。频繁更新的页面可能需要较短的 TTL，而稳定的页面通常可以使用较长的 TTL。当翻译发生变化时，应清除或刷新受影响的语言版本，而不是等待 TTL 过期。这有助于防止访客收到过时的翻译。缓存策略可以包括：
- 为频繁更新的内容设置较短的 TTL
- 为稳定页面设置更长的 TTL
- 特定 URL 的缓存规则
- 手动清除缓存
- 更新后自动清除缓存
多语言网站缓存的最佳实践
精心规划的缓存设置可以让多语言网站速度更快，同时避免访问者收到错误或过时的翻译。关键在于让翻译系统和缓存层协同工作，同时清晰区分每个语言版本。.
结合翻译与缓存
翻译和缓存应作为同一内容交付流程的一部分协同工作。翻译层决定应返回哪个本地化版本，而缓存层则存储该响应以供后续请求使用。重要的考虑因素是时机：应在缓存响应之前确定语言。这确保缓存存储的是实际请求的翻译后响应，而不是可能被复用于另一种语言的模糊版本。.
对于使用自动翻译的网站，诸如 Linguise 这样的翻译解决方案可以通过自动生成本地化内容来简化这一过程，同时允许翻译后的页面与网站现有的缓存设置协同工作。这对于多语言网站非常有用，因为手动管理翻译版本并使其与缓存内容保持同步可能会变得更加复杂。
最佳实践： 在启用整页缓存之前，请确保您的翻译系统和缓存层在如何识别语言版本方面达成一致。
使用特定语言的缓存键
每个翻译后的响应都应映射到正确的缓存变体。基于 URL 的语言结构使这更容易，因为每种语言已经拥有不同的 URL，而基于标头或 Cookie 的设置则需要额外的缓存配置。.
最佳实践： 尽可能优先使用特定语言的 URL，例如：
- /en/about/ → 英文
- /fr/about/ → 法语
- /de/about/ → 德语
这样可以清晰区分不同语言版本，并降低跨语言缓存命中的风险。.
设置缓存控制和 TTL
Cache-Control 标头和 TTL 决定浏览器、CDN 和反向代理如何处理缓存内容。正确设置它们有助于在网站性能与提供最新翻译的需求之间取得平衡。.
很少更改的页面通常可以缓存更长时间，而频繁更新的内容则应使用较短的 TTL。正确的设置取决于您网站内容和翻译的更新频率。.
最佳实践： 例如，您可以为静态多语言着陆页使用较长的 TTL，而为频繁变化的产品或新闻页面使用较短的 TTL。请始终测试配置，以确保更新后的内容在预期时可用。
更新后清除缓存
当内容或翻译发生变化时，请清除或刷新受影响的缓存响应，而不是仅依赖 TTL 过期。这有助于确保访客在所有受影响的语言中都能收到最新版本。.
最佳实践： 将缓存失效纳入您的内容更新工作流程，并确保覆盖所有受影响的语言版本。
测试缓存的多语言页面
测试非常重要，因为缓存问题在日常浏览中并不总是可见的。一个页面在直接访问时可能看起来正常，但在从缓存响应中提供时却返回了错误的语言。.
在配置或更改缓存规则后，请测试每个语言版本。检查首次请求和后续请求，以确认始终返回正确的缓存响应。.
最佳实践： 测试以下场景：
- 以不同语言打开同一页面
- 重新加载缓存的页面
- 切换语言
- 更新翻译
- 清除缓存后检查页面
- 抓取特定语言的 URL
多语言缓存检查清单
在将多语言缓存设置投入生产环境之前，请使用一个简单的检查清单来验证语言检测、缓存和内容更新是否能够正确协同工作。.
最佳实践清单：
- 为每个语言版本提供唯一的 URL 或缓存变体
- 使用特定语言的缓存键
- 配置适当的 Cache-Control 标头
- 根据内容更新频率设置 TTL
- 更新后清除受影响的语言版本
- 测试所有支持语言的缓存页面
- 检查是否存在语言错误的响应
- 检查过时的翻译内容
- 使用搜索引擎爬虫验证特定语言的 URL
结论
有效缓存多语言网站需要在网站性能与向每位访客提供正确、最新的语言版本之间取得平衡。通过使用特定语言的缓存键、适当的 TTL 以及可靠的缓存失效机制，您可以减少服务器请求，同时防止出现语言错误和过时内容。.
为了更简单地管理翻译内容， 注册 Linguise ，并通过自动翻译简化您的多语言网站工作流程，同时保持您的 本地化内容 快速且易于管理。
