ThemesCorners
博客
12 分钟阅读作者 ThemesCorners

用 Next.js 做无头 WordPress——务实指南

什么时候该走无头、什么时候不该，以及我们说「该走」时实际使用的栈。

这个问题我们一周收到一次：「我们要不要用 Next.js 把 WordPress 站点改成无头？」诚实的答案是「大概率不要，但这里说清楚什么时候要、要怎么做」。下面就是那个答案的完整版。

「无头」到底是什么

传统 WordPress 架构里，WordPress 直接生成访客看到的 HTML。跑后台的同一段 PHP 也渲染公开页面。

无头架构里，WordPress 只提供数据——通过 REST API 或 WPGraphQL。一个独立前端（Next.js、Astro、SvelteKit、Nuxt——最常见的是 Next.js）拉取数据并渲染公开站点。

你保留：

  • 内容作者熟悉的 WordPress 编辑器体验
  • 后端插件生态（WooCommerce、ACF 等）

你放弃：

  • 「随手就能用」的实时预览
  • 大多数前端 WordPress 插件（页面构建器、Cookie 横幅、弹窗）
  • 部分 SEO 插件的前端输出（你得自己重做）

你获得：

  • 公开站点显著更快（通常 LCP 提升 60–80%）
  • 现代开发体验（TypeScript、热更新、组件库）
  • 解耦部署——前后端独立发布
  • 前端可以部署到任何现代主机（Vercel、Netlify、Cloudflare Pages）

什么时候走无头

数学算得过来的真实场景：

是——高流量出版/内容站

如果你发文多、流量大、要为 Core Web Vitals 优化，无头胜出。被缓存的 PHP WordPress 与一个搭得好的 Next.js 前端之间的性能差距是真实可测的。

是——多渠道内容（Web + 移动 App + 语音）

如果同一份内容还要喂给移动 App、智能音箱或合作方集成，无头能让你用同一套 API 服务所有消费者。从传统 WordPress 实例里抽数据给非 Web 用，相当痛苦。

是——设计系统要求 React 组件

如果你品牌方有 React 组件库，并希望 WordPress 内容通过它渲染，无头是最干净的答案。

也许——拥有强力开发团队的企业站

如果你团队里有 React 工程师，他们宁愿在 Next.js 里工作而不是 PHP，那即使没有性能论据，无头也合理。开发者幸福度也是真实输入。

什么时候不要走无头

同样诚实：

不——典型小企业站

如果你的站就是 20 个页面的宣传册加博客和一个联系表单，无头投入远超回报。传统 WordPress + 好主题，能用 10% 的复杂度达到无头 90% 的效果。

不——WooCommerce 商店

这是最难的情形。WooCommerce 有数百个前端触点——购物车更新、结账流程、支付网关集成、订阅管理。在无头前端里把这些全重做，是几个月工作，最后还会得到一个比 WooCommerce 默认更微妙更差的版本。直接用 WooCommerce Blocks。

不——依赖实时预览的编辑

如果你的作者们就靠实时预览（「改个词、刷新、看效果」）干活，无头会让他们抓狂。无头里的预览总是会稍微落后——这是设计如此。

不——重度依赖插件

看你启用的插件清单。是否依赖任何会注入前端输出的插件（Yoast 的 UI 微调、页面构建器运行时、Mailchimp 弹窗、聊天 widget）？每一个在无头里都是一个独立迁移任务。超过五个，迁移成本就要爆炸。

我们用的栈

当我们对无头点头时，下面是确切的栈：

后端（WordPress）

  • WordPress 加编辑器、WPGraphQL、最少的前端插件。
  • Advanced Custom Fields，配合 ACF + WPGraphQL 桥接处理结构化内容。
  • WP Migrate DB Pro 或同类工具做环境同步。
  • 不要前端插件。 关闭一切会为公开站点生成 HTML 的插件——根本没有公开站点要 WordPress 渲染。
  • 跑在小型托管 WP 套餐（$20–35/月就够——负载低很多）。

前端（Next.js）

  • Next.js 16+，App Router 与 Cache Components。
  • TypeScript、Tailwind CSS v4、shadcn/ui 做组件。
  • 若部分内容写在 WordPress 之外的 MDX 中，加 next-mdx-remote。
  • 部署到 Vercel（或 Cloudflare Pages、Netlify）。

缓存策略

最微妙的一块。无头缓存是分层的：

  1. 静态生成 用于很少变化的页面（关于、联系、归档）。
  2. Cache Components（Next 16）用于偶尔变化的页面，按页打 tag。
  3. 按需重新校验——文章发布时，WordPress webhook 命中一个 Next.js 端点，调用 revalidateTag('post-123')。
  4. 后台刷新 用 cron 处理首页与高流量页面。

预览的身份验证

让预览不烦人，唯一办法是设带身份验证的预览路由：

// app/preview/route.ts
import { draftMode } from 'next/headers';

export async function GET(req: Request) {
  const url = new URL(req.url);
  const secret = url.searchParams.get('secret');
  const slug = url.searchParams.get('slug');
  if (secret !== process.env.PREVIEW_SECRET) {
    return new Response('Invalid token', { status: 401 });
  }
  draftMode().enable();
  return Response.redirect(new URL(`/blog/${slug}`, req.url));
}

然后在 WordPress 后台为每篇文章加一个自定义按钮，指向 /preview?secret=...&slug=...。

迁移顺序

对一个想要无头化的现存站点：

  1. 审计内容类型。 列出每种文章类型、自定义字段与分类法。这份清单上漏的，新前端就会缺。
  2. 审计前端插件。 列出每个会向公开站点输出 HTML、JS 或 CSS 的插件。每一个都是一项重做任务。
  3. 并行搭建新前端。 Next.js 站点跑在子域（如 next.example.com），内容渲染完整，先不接流量。
  4. 两套站点并行至少 30 天。 把 analytics、转化率、错误率并排对比。
  5. 只在功能对等被验证后切换 DNS。 把 WordPress 的 wp-admin 留在 admin.example.com 可访问。
  6. 再观察 90 天才宣布成功。有些故障要等到季度任务才暴露。

诚实的总结

无头 WordPress 是为那少数真正需要它的站点而生的好技术。对其余所有人，一个搭得好的传统 WordPress 站点配上快速主题（比如我们的）就能在小得多的复杂度下拿到 90% 的好处。

按真实编辑工作流和真实性能差距来决定——而不是因为「无头」听起来更现代。它确实更现代，也确实更费工。

相关文章