早在 2021 年，一个客户给了我一份我听过大约四十次的简报："我们想要编辑们知道的 WordPress 后端，但网站需要很快。像，真的很快。"他们在 Vercel 营销页面上读到了一些关于无头架构的内容。在我说话之前他们就被说服了。我接下这个项目，在 Vercel 上构建了一个从 WordPress REST API 获取内容的 Next.js 前端，并交付了一些真正令人印象深刻的东西。Lighthouse 分数很漂亮。客户大约三个月内很喜欢它。fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.
然后他们的营销经理想添加一个弹出窗口表单。然后是一个会员插件。然后是与帖子类别相关联的条件逻辑的实时聊天。慢慢地，悄悄地，整个设置开始吱吱呀呀地响。
那个项目教给我的关于无头 WordPress 的真实限制比任何教程都多。所以让我给你诚实的画面。
"Vercel 上的无头 WordPress"实际上是什么意思
值得在这里精确一点，因为人们对这个术语的使用很宽松。
你用 WordPress（通常在单独的服务器上运行，或托管在 Kinsta 或 WP Engine 这样的管理主机上，甚至廉价 VPS 上）纯粹作为内容管理系统。没有主题提供前端服务。相反，你的 Next.js（或 Nuxt、Astro、SvelteKit）应用通过 WordPress REST API 或 WPGraphQL 获取内容，然后 Vercel 构建并部署该前端。Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.
Vercel 本身不托管 WordPress。这是硬性限制。WordPress 需要 PHP、数据库（MySQL）和服务器端执行。Vercel 运行 Node.js 无服务器函数和静态文件。你不能像在 cPanel 服务器上那样把 WordPress 安装直接放到 Vercel 上。
所以当有人说"在 Vercel 上托管 WordPress"时，他们的实际意思是：在 Vercel 上托管前端，而 WordPress 运行在完全不同的地方。这个区别至关重要，我对这个细节在博客文章中被忽视的频率感到震惊。frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.
这个架构真正闪耀的时刻
我想在这里公平对待。我已经交付过我真正为之骄傲的无头 WordPress + Vercel 项目，存在特定条件下该架构的复杂性是合理的。
高流量编辑或媒体网站
Seahawk 在 2022 年为一家体育媒体发行商做了一个项目。每天数万次页面浏览，十二人编辑团队，编辑们坚决拒绝离开 WordPress。我们用 Incremental Static Regeneration（ISR）在 Vercel 上构建了 Next.js 前端，设置 60 秒重新验证窗口。在大型比赛日，源 WordPress 服务器几乎没有受到压力。Vercel 的边缘网络吸收了流量峰值，无需进行任何扩展讨论。
对于内容成批变化的网站（文章上线，而非每两分钟编辑一次），ISR 是完美契合。你在边缘获得静态文件性能，同时保持合理新鲜的内容。
需要极端前端灵活性的网站
如果你的设计师想要自定义滚动动画、复杂的组件过渡，或在页面中间嵌入基于 React 的交互式工具，传统 WordPress 主题会一直与你对抗。分离的前端把这个控制权完全交还给开发者。WordPress 主题的设计限制就此消失。
已经深入 Node/React 生态系统的开发团队
如果你的团队整天在构建 React 应用，把 PHP 当作外语，强行让他们进行 WordPress 主题开发会带来真正的痛苦。Headless 让他们留在自己熟悉的世界，同时给内容编辑提供一个他们已经知道的工具。对合适的团队来说，这是真正的生产力提升。
我实际使用的工具栈
如果我今天选择 Headless WordPress + Vercel，这就是我的栈：
- WordPress 主机：Kinsta 或 Cloudways。两者都能处理托管的 MySQL 备份，我无需操心。 Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
- GraphQL 层：WPGraphQL 插件。对于复杂的文章类型，它的内容查询比 REST API 要清洁得多。 WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
- 前端框架：Next.js。如果团队对 App Router 有把握就用它，如果需要更快地交接给经验不足的人就用 Pages Router。 Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
- 部署：Vercel，当然。每个 PR 的预览部署本身就值了。 Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
- 按需重新验证：WordPress Webhooks（通过自定义插件或 Advanced Custom Fields 钩子）在内容发布时 ping 一个 Vercel 重新验证端点。 WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
- 预览内容：使用 @wpengine/headless 包或自定义 Next.js 草稿模式设置，让编辑无需重建就能预览未发布的文章。 The
@wpengine/headlesspackage or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.
关于预览功能的最后一点花了我比我想承认的还要长的时间才搞对。编辑们希望在 WordPress 中点击"预览"，然后看到完全相同的实时发布效果。在解耦架构中，正确地将这部分连接起来需要花费整整一天的工作。
问题所在（确实存在问题）
好的。我得坦白跟你说，因为这是大多数"无头架构是未来"的文章都跳过的部分。
插件。太多太多的插件。
WordPress 的强大之处在于其插件生态系统。WooCommerce、Gravity Forms、会员插件、预订系统、高级 SEO 工具如 Yoast（是的，Yoast 依然可用，但其元标签的前端渲染需要额外的连接工作）、滑块插件，任何涉及前端的东西。在传统架构中，插件直接将 PHP 渲染到页面中。在无头架构中，除非你明确构建了前端组件来复制其输出，否则它不会有任何可见效果。
我在 2023 年末有个客户在项目中途找到我（不是 Seahawk 的项目，是我接手的别人的烂摊子）。他们原本想着好好考虑去采用了无头架构，然后试图加入 WooCommerce。接下来是四个月的迂回，用 React 构建自定义购物车和结账流程，调用 WooCommerce 的 REST API，手动处理 Stripe 网络钩子，基本上重新发明了 WooCommerce 已经构建好的轮子。时间成本大约是直接使用传统的 WordPress + WooCommerce 架构的三倍。
无头 WooCommerce 是可行的。WooCommerce 已经很好地记录了他们的 REST API。但"可行"和"值得"是两个不同的问题。WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.
预览体验永远无法完全匹配
我已经交付了六七个无头 WordPress 项目，还从未有过一个客户对预览工作流程完全满意过。点击 WordPress 中的"预览"和看到实际呈现的内容之间总是存在差距。有时是草稿模式 cookie 问题。有时是 ISR 缓存时序问题。来自传统 WordPress 架构的编辑会感到困惑，抱怨声虽然不大但会持续不断。
两套系统要维护
这听起来很显然,但它确实会偷偷摸摸地给团队带来麻烦。你现在要运维两套独立的基础设施:WordPress服务器(有自己的更新、安全补丁、插件冲突、数据库备份)和Vercel前端(有自己的构建管道、环境变量、无服务函数限制)。当凌晨2点出问题时,你要排查的地方是原来的两倍。
在Seahawk,我们遇到过WordPress插件自动更新并悄悄改变了REST API响应结构的项目,结果破坏了前端组件。WordPress端没有抛出任何错误。只是实时网站上出现了静默内容缺失。这种故障比传统的WordPress错误确实更难发现。
实时内容很棘手
如果你的网站内容频繁变化(想象实时比分、股票价格、用户生成的评论,任何需要亚分钟级新鲜度的内容),ISR的重新验证模型就不适用。你最后要么提供过期数据,要么在每次请求时都回源到WordPress后端,这样就失去了性能优势的很大一部分。
成本:没有人会在方案书里提这个
让我具体讲讲钱和时间,因为我见过很多代理商在这类项目上严重低估成本。
- 初期构建开销:与等复杂度的传统WordPress构建相比,至少预留30-40%更多的开发时间。这个差距是真实存在的。我在多个项目中追踪过。 Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
- Vercel定价:免费的Hobby计划不适合商业项目。Pro是$20/月每座位,高流量网站的带宽和无服务函数执行成本会快速堆积。在承诺之前先算清楚成本。 The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
- WordPress托管:你仍然需要一个可靠的托管主机。那又是$30-100/月,取决于流量。所以你的"廉价静态托管"说法很快就破产了。 You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
- 持续维护:两个平台,两套潜在问题。与传统的托管WordPress设置相比,要在月度维保时间上至少多算20%。 Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.
我什么时候才会真正推荐它
综合我刚才说的一切，以下是我会告诉客户 headless WordPress on Vercel 值得权衡的具体场景：
- 网站内容丰富且读取量大：主要是文章或登陆页面，而非交易流程content-heavy and read-heavy: mostly articles or landing pages, not transactional flows
- 内容团队已经熟悉 WordPress，不会考虑切换 CMSalready knows WordPress and won't entertain switching CMS
- 大规模性能是真实的业务需求，而不仅仅是锦上添花
- 开发团队熟悉 React 和现代 JavaScript 工具链
- 简案中没有复杂的插件依赖，或者你已经明确规避了它们 are in the brief, or you've explicitly scoped around them
- 有一位长期技术负责人到位，理解技术栈的两个方面
以下是我会提出异议的场景：
- 客户需要 WooCommerce 或任何依赖插件的前端功能
- 团队规模很小，无法承担两个系统的维护开销
- 编辑需要快速、熟悉的预览工作流，但没有预算来正确构建它
- 网站有用户账户、动态个性化或实时数据需求
- 客户就是因为听起来"现代"而想要它
就是最后那一个。我听到这个理由的频率比我想要的高得多。
值得首先考虑的替代方案
在默认使用这个技术栈之前，我至少会把这些选项摆出来：
- 传统的 WordPress 配上好的托管主机：Kinsta、Cloudways 或 Rocket.net 加上适当的缓存（WP Rocket 或 Nginx FastCGI 缓存）可以让你的 Lighthouse 评分达到 90 多分，而根本不需要解耦任何东西。我见过这出乎假设必须采用无头架构才能获得速度的客户的意料。 Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
- WP Engine 的 Faust.js：专为无头 WordPress 构建，它处理了很多你原本需要自己构建的样板代码（预览模式、身份验证、路由）。如果你已经致力于这个架构，值得看一看。 Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
- 专用的无头 CMS：如果你的团队实际上并不需要 WordPress 的插件生态，Sanity 或 Contentful 这样的东西可能就是托管在 Vercel 上的 Next.js 前端的更清晰的选择。完全不需要维护 PHP 服务器。 If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.
---
常见问题
我可以直接把 WordPress 部署到 Vercel 吗？
不行。WordPress 需要 PHP 和 MySQL 数据库。Vercel 的基础设施是围绕 Node.js 无服务器函数和静态文件服务构建的。你可以把 Next.js（或其他 JavaScript）前端部署到 Vercel，然后让前端从其他地方托管的 WordPress 实例中获取内容，但 WordPress 本身运行在单独的服务器上。
无头 WordPress 会伤害我的 SEO 吗？
本身不会，但如果你设置不当就会。使用 Next.js 你可以获得服务端渲染和静态生成，两者都能生成完整渲染的 HTML，搜索引擎可以无问题地索引。风险区域包括：元标签处理（Yoast 的输出需要由你的前端明确消费和渲染）和网站地图生成（你需要在 Next.js 中构建一个动态网站地图路由来从 WordPress 拉取数据）。把这些搞对了，SEO 就没问题。
Vercel 的免费计划对于无头 WordPress 前端来说足够吗？
对于个人项目或原型，可能足够。对于商业网站，不够。Vercel 的服务条款禁止 Hobby 计划的商业使用，而且任何有真实流量的网站都会触及无服务器函数调用限制。从第一天起就为 Pro 计划预算。
我如何在 Next.js 中处理 WordPress 预览模式？
Next.js 有内置的 Draft Mode（在 Pages Router 中之前叫 Preview Mode）。模式是：在 Next.js 中创建一个 /api/preview 路由来设置预览 cookie，然后配置 WordPress 的"预览"按钮来用一个密钥令牌调用该路由。当 cookie 存在时，你的页面组件直接从 WordPress 获取草稿内容，而不是缓存的静态版本。WPGraphQL 本身支持草稿文章查询，这就是为什么我在这个特定流程中更倾向于用它而不是 REST API。/api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.
表单和联系页面呢？
表单是插件到无头架构迁移中比较简洁的一种。Gravity Forms 提交可以直接发送到 Gravity Forms REST API。或者，完全跳过 WordPress 表单，改用 Netlify Forms（虽然你用的是 Vercel）或前端的 Formspree 集成。说实话，对于表单，我通常就直接用 Formspree，一个下午就搞定了。Formspree and call it done in an afternoon.
---
Vercel 上的无头 WordPress 是真实的架构，有真实的用途。它不是万能方案，也不是噱头。从中获益最多的团队是那些对自己放弃了什么有清醒认识、为额外的构建时间做了预算，并且有特定的性能或灵活性问题需要解决的团队。如果这听起来像你的项目，那就值得一试。如果不是，还是省去这份复杂性吧。