在 Headless WordPress + Nuxt.js 的架构中，WordPress 作为内容后端通过 REST API 提供数据，Nuxt.js 作为前端负责渲染页面。这种分离带来了灵活性和可扩展性，但也引入了一个核心挑战：每次页面请求都可能触发多次 WordPress API 调用，在高流量场景下不仅拖慢响应速度，还会给服务器带来不必要的压力。本文将从四个维度系统性地介绍在 Nuxt.js 项目中优化 WordPress REST API 数据缓存的多层策略，并给出可直接使用的代码示例。
为什么缓存至关重要
一个典型的 Nuxt.js 文章列表页可能需要请求三到四个 WordPress 端点：文章列表（/wp/v2/posts）、分类目录（/wp/v2/categories）、标签（/wp/v2/tags）和媒体信息（/wp/v2/media）。如果每个访问者都触发完整的 API 调用链，服务器负载会呈线性增长。以日均一万次页面浏览为例，没有缓存意味着 WordPress 服务器每天要处理三四万次 API 请求。合理使用缓存可以将重复请求的响应时间从数百毫秒降至几毫秒，用户体验提升显著，同时还能降低服务器成本。
第一层：Nuxt.js useFetch 内置缓存
Nuxt 3 内置的 useFetch 和 useAsyncData 组合式函数提供了开箱即用的缓存机制。这两个函数的 key 参数是缓存的核心——具有相同 key 的请求在服务端渲染（SSR）期间只会执行一次，后续组件复用同一份数据，客户端导航时也会优先读取已有数据而非发起新请求。
// composables/usePosts.ts
export const usePosts = (page: number) => {
return useFetch('/wp/v2/posts', {
baseURL: 'https://api.example.com/wp-json',
key: `posts-page-${page}`,
query: { page, per_page: 10, _embed: true },
// 客户端缓存 5 分钟，过期后静默刷新
getCachedData: (key) => {
const nuxtApp = useNuxtApp()
const data = nuxtApp.payload.data[key]
if (!data) return
const age = Date.now() - (nuxtApp._cachedTime?.[key] || 0)
if (age < 5 * 60 * 1000) return data
}
})
}上面的代码通过 getCachedData 实现了 stale-while-revalidate 模式：请求到达时，如果在 5 分钟内有缓存数据则直接返回，无需等待 API；过期后下一次请求仍返回旧数据，但同时在后台发起新请求更新缓存，确保用户始终看到「足够新」的内容而不用等待。
第二层：Nitro Server Route Rules
Nuxt 3 的 Nitro 服务器引擎支持通过 routeRules 配置声明式缓存策略，这是目前官方最推荐的做法。在 nuxt.config.ts 中即可定义每个路由的缓存行为，无需额外编写缓存逻辑：
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
// 首页缓存 5 分钟
'/': { swr: 300 },
// 文章相关页面缓存 10 分钟
'/posts/**': { swr: 600 },
// 分类页面缓存 1 小时（变化频率低）
'/categories/**': { swr: 3600 },
// API 代理路由
'/api/**': {
cors: true,
headers: { 'Access-Control-Max-Age': '86400' }
}
},
nitro: {
storage: {
redis: {
driver: 'redis',
host: '127.0.0.1',
port: 6379
}
}
}
})swr（stale-while-revalidate）参数指定缓存有效期（秒）。Nitro 在有效期内直接返回缓存内容，过期后先返回旧版本同时后台生成新内容并更新缓存。默认情况下 Nitro 使用内存存储缓存数据，服务重启即丢失。将存储驱动切换为 Redis 后，缓存数据持久化且可在多进程/多实例间共享，适合生产环境部署。Redis 连接配置也支持通过环境变量动态注入，方便在不同部署环境中切换。
第三层：WordPress REST API 缓存控制
除了在前端层做缓存，在 WordPress 端也可以施加缓存控制以减轻 API 服务器的计算压力。REST API 默认不发送强缓存头，我们可以通过 rest_post_dispatch 过滤器为 GET 请求添加 Cache-Control 头：
// WordPress 主题 functions.php 或自定义插件
add_filter('rest_post_dispatch', function($response, $server, $request) {
$method = $request->get_method();
if ($method !== 'GET') return $response;
$response->header('Cache-Control', 'public, max-age=300, s-maxage=600');
$response->header('Vary', 'Accept-Encoding');
return $response;
}, 10, 3);这段代码告诉中间代理和 CDN：对于公开的 GET 请求，浏览器可缓存 300 秒，共享缓存（CDN）可缓存 600 秒。配合 WordPress 的对象缓存插件（如 Redis Object Cache 或 W3 Total Cache 的数据库缓存），将数据库查询结果缓存在内存中，API 响应速度可从几百毫秒降至几十毫秒。
第四层：CDN 边缘缓存与缓存失效策略
对于生产环境，CDN 是最外层的缓存防线。将 Nuxt.js 的 SSR 输出和静态资源通过 Cloudflare、Vercel Edge Network 或阿里云 CDN 分发，可以将内容缓存到离用户最近的边缘节点，全球访问延迟大幅下降。配合 HTTP 响应头中的 stale-while-revalidate 指令，即使后端 API 暂时不可用（如服务器维护或宕机），CDN 也能持续提供旧版本内容，保证网站始终可访问而不出现白屏或错误页面。
但缓存带来了一个新问题：如何保证内容及时更新？关键在于建立缓存失效机制。推荐的做法是在 WordPress 端配置 Webhook——当文章发布或更新时，向 Nuxt.js 服务发送一个 HTTP POST 请求，触发指定页面的缓存清除：
// WordPress - 文章状态变更时触发 Webhook
add_action('transition_post_status', function($new, $old, $post) {
if ($post->post_type !== 'post') return;
if ($new !== 'publish' && $old !== 'publish') return;
wp_remote_post('https://your-nuxt-app.com/api/clear-cache', [
'body' => json_encode(['slug' => $post->post_name]),
'headers' => ['Content-Type' => 'application/json']
]);
}, 10, 3);在 Nuxt.js 端，通过 server/api/clear-cache.ts 接收 Webhook，调用 Nitro 的缓存存储接口清除对应路由的缓存数据。这样就实现了「发布即生效」的内容更新体验，无需等待缓存自然过期。
实战组合策略与最佳实践
一个成熟项目的缓存架构应该是多层次的，从外到内依次为：浏览器缓存 → CDN边缘节点 → Nitro服务端缓存 → WordPress对象缓存 → MySQL查询缓存。每一层各司其职，离用户越近的层拦截越多的请求。具体实施建议分环境配置：
- 本地开发环境：仅使用 useFetch 的 key 去重，防止 SSR 期间对同一 API 发起重复请求。不建议开启 Nitro 缓存，否则修改代码后可能看到旧数据
- 预览/测试环境：启用 Nitro swr 内存缓存，设定较短的过期时间（60-120 秒），方便测试内容变更效果
- 生产环境：组合使用 Nitro Redis 持久化缓存 + CDN 边缘缓存，页面级缓存 5-10 分钟，并配置 Webhook 主动失效机制
另外，需要注意以下边界情况：包含用户个性化内容的页面（用户中心、购物车、订单列表等）务必排除在缓存策略之外，避免用户看到其他人的私密数据。可以通过 routeRules 的 headers 选项根据 Cookie 区分已登录用户，或在 Nuxt 中间件中动态判断当前请求是否应跳过缓存。对于需要实时数据的场景（如库存数量、竞拍剩余时间等），建议将这些数据改为客户端异步加载，不在 SSR 层面缓存。
总结
在 Headless WordPress + Nuxt.js 架构中实施多层缓存策略，能将页面响应时间从秒级优化到毫秒级，同时大幅降低 WordPress 服务器的 API 请求压力。从 useFetch 的请求去重到 Nitro 的服务端缓存，再到 CDN 的边缘分发和 Webhook 驱动的缓存失效——这四层协同工作，能让你的 Headless WordPress 站点拥有媲美纯静态站点的访问速度。在实际落地时，建议先从 Nitro routeRules 的 swr 配置入手，这是投入产出比最高的优化手段，配置简单但效果显著。
