一个客户在2021年给我打电话——曼彻斯特的一家中等规模电商品牌，拥有约40,000个SKU、多个地区店铺——他们很生气。在一个18个月内花费£180,000进行的无头Shopify构建（使用Next.js前端）中，他们的页面加载时间比他们替换掉的Shopify主题还要慢。他们的开发团队从一个承包商增长到了四个人。内容编辑需要开发者在场才能发布一篇博文。slower than the Shopify theme they'd replaced. Their development team had grown from one contractor to four. Content editors needed a developer present just to push a blog post live.
无头架构曾被向他们推销为未来。从技术角度讲，确实是这样。但没人告诉他们运营它的实际成本会有多高。
在Seahawk Media，我已经构建或监督了超过12,000个网站的构建。无头架构在其中只有8–10%的情况下是正确的选择。其余90%的情况？那会是一场灾难——成本高昂、交付缓慢、维护令人难受。这篇文章讲的是如何在你已经签支票之前，就知道你的项目属于哪一种情况。
---
"无头"在实践中实际意味着什么
让我们先把定义说清楚。传统 CMS——WordPress、Squarespace，无论什么——将内容管理后端与前端展示层耦合在一起。它们彼此原生对话。Headless 解耦了它们。你的 CMS（Contentful、Sanity、Strapi、Headless 模式下的 WordPress）变成纯内容 API。你的前端——Next.js、Nuxt、Astro、SvelteKit，随你选择——获取那些内容并以它想要的任何方式渲染。
想法很简单。复杂性在其他地方层层出现。
实际在项目中出现的技术栈
实际上，当有人说"Headless"时，他们通常指的是以下几种组合中的一种：
- Contentful 或 Sanity 作为 CMS，通过 REST 或 GraphQL 提供 JSON as the CMS, serving JSON over REST or GraphQL
- 前端使用 Next.js，采用静态生成（SSG）或服务器端渲染（SSR） on the front end, either statically generated (SSG) or server-side rendered (SSR)
- Vercel 或 Netlify 进行部署和边缘函数 for deployment and edge functions
- 如果涉及电商，则使用 Shopify Storefront API 或 BigCommerce or BigCommerce if there's commerce involved
- 某种版本的 Algolia 用于搜索，因为原生搜索选项通常很糟Algolia for search, because the native search options are usually rubbish
这些都是独立的供应商关系、独立的账单行项目，以及独立的可能在周五凌晨 2 点出问题的东西。
---
采用 Headless 架构的真正理由
关键是这样——确实存在真实、正当的理由这样做。我不是在否定这个架构。我只是厌倦了它被不加区别地应用。
多渠道内容分发是最有力的论证。如果同一内容需要出现在网站、移动应用、自助终端显示屏和智能电视界面上，一个耦合的 CMS 就会变得真正麻烦。一个所有四个界面都查询的内容 API？那确实是有道理的。Seahawk 在迪拜有一个酒店业客户——那种拥有对外网站、员工内部应用和全物业数字标牌的度假村集团。单个 Sanity 实例为所有这些供应内容。那是正确的决定，这没有疑问。 is the strongest argument. If the same content needs to appear on a website, a mobile app, a kiosk display, and a smart TV interface, a coupled CMS becomes genuinely painful. One content API that all four surfaces query? That actually makes sense. Seahawk had a hospitality client in Dubai — one of those resort groups with a public-facing site, an internal staff app, and digital signage across the property. Single Sanity instance feeding all of it. That was the right call, full stop.
真实规模下的性能是第二个正当理由。从 CDN 边界提供的静态生成页面在速度上超越 PHP 渲染的 WordPress 页面，不管你的服务器优化得有多好。当你处理每月数百万页面浏览量时，那些毫秒级的差异会累积成有意义的收入差异。Google 的研究已经反复记录了加载速度和转化率之间的相关性——这不是理论。 is the second legitimate argument. Statically generated pages served from a CDN edge are fast in a way that PHP-rendered WordPress pages simply aren't, regardless of how well you've optimised your server. When you're talking about millions of page views per month, those milliseconds compound into meaningful revenue differences. Google's research has documented the correlation between load speed and conversion rate repeatedly — it's not theoretical.
团队分离也很重要，但仅限于足够大的组织有独立的前端和后端团队。如果你的内容团队是一个 20 人的市场营销部门，想要独立于工程团队运作，CMS 和前端之间的干净 API 契约可以让双方在互不阻碍的情况下工作。 matters too, though only for organisations big enough to have separate front-end and back-end teams. If your content team is a 20-person marketing department that wants to move independently of your engineering team, a clean API contract between CMS and front end lets both sides work without blocking each other.
那三个案例？确实值得复杂性成本。其他一切通常都是被装扮成架构的一厢情愿。
---
Headless 何时只是昂贵的过度设计
伦敦会计师事务所的五页宣传册网站不需要 Headless 架构。有一个开发者做顾问的 200 产品 WooCommerce 店铺也不需要。
我经常看到这个错误,尤其是来自刚发现 Next.js 的开发者,他们想把它用在所有事情上。(我自己在 2019 年就犯过这个错误——为一个小慈善机构客户构建了一个无头博客,花了三天时间配置 webhook 来触发 Netlify 重新构建新文章,收了他们的钱,结果每当出问题时他们还是会打电话给我。)问题在于无头架构把运营复杂性从 CMS 转移到了基础设施。WordPress 会自动更新。你的自定义 Next.js + Contentful 流程不会。
无头架构通常成本大于回报的具体场景:
- 小型内容团队——如果只有一两个人管理所有内容,像 WordPress 这样的真正耦合的 CMS 的编辑体验确实比无头 CMS 更好。预览环境更难设置。内联编辑功能消失了。所见即所得被削弱了。 — if one or two people manage all the content, the editorial DX of a proper coupled CMS like WordPress is genuinely better than a headless CMS. Preview environments are harder. Inline editing is gone. WYSIWYG is neutered.
- 预算紧张——一个真正的无头构建的开发成本是相当的 WordPress 构建的 2-3 倍,而且持续维护成本也更高。如果预算是制约因素,这笔钱几乎总是用在别处能发挥更大的作用。 — a proper headless build costs 2–3x a comparable WordPress build to develop, and the ongoing maintenance is higher. If budget is a constraint, that money almost always does more good elsewhere.
- 内容频繁更改——静态生成意味着构建时间。每天发布 50 篇文章的新闻媒体不希望每次都要等待 8 分钟才能完成整个网站重新构建。(是的,增量静态再生成会有帮助。但它也增加了自己的复杂性。) — static generation means build times. A news publisher pushing 50 articles a day doesn't want to wait 8 minutes for a full site rebuild every time. (Yes, incremental static regeneration helps. It also adds its own complexity.)
- 没有专职的 DevOps——有人必须负责部署流程、CDN 配置、环境变量、预览 URL。在小团队中,这个人通常就是也在做所有其他事情的开发者。 — someone has to own the deployment pipeline, the CDN config, the environment variables, the preview URLs. On a small team, that someone is usually the developer who's also doing everything else.
---
WordPress 无头折中方案
我想反驳的一点是"传统 WordPress"和"带有独立 CMS 的完全无头"之间的假二分法。有一个中间路径对某一类项目来说效果非常好。
WordPress 作为无头后端——使用 WP REST API 或 WPGraphQL——给了你客户已经熟悉的内容管理体验(说实话,大多数客户都了解 WordPress),结合了现代前端的灵活性。你不需要为 Contentful 付费。你不需要重新培训任何人。编辑团队继续使用 Gutenberg。前端可以是任何适合项目的框架。WP REST API or WPGraphQL — gives you the content management experience your clients already know (and honestly, most clients know WordPress), combined with the flexibility of a modern front end. You're not paying for Contentful. You're not retraining anyone. The editorial team keeps Gutenberg. The front end gets to be whatever framework suits the project.
在过去四年里，我在大概30-40个项目上用过这个模式。它特别适合那些在WordPress中已有大量内容库、不想迁移但想要React前端来提升性能或交互性的营销网站。代价是WPGraphQL插件的维护会很繁琐，而且你仍然在运行PHP服务器——你并没有完全摆脱WordPress主机。
---
选择无头CMS：实用对比
不同的无头CMS并不相同，而且当人们对前端框架感到兴奋时，这个选择的重要性远比他们承认的要大。
Contentful
企业级选项。API稳定，SDK完善，编辑界面还不错。价格是痛点——免费套餐对小型项目确实有用，但一旦超过限制，你就得花$300+/月，而且还没做什么有意思的事。我会在有真实预算的项目和需要适当权限和工作流管理的组织上选择Contentful。
Sanity
我个人在大多数中等规模无头项目上的首选。GROQ查询语言一旦花一天时间学习就很强大，Sanity Studio以Contentful无法做到的方式可定制，实时协作功能也很出色。价格更合理。缺点是非技术内容编辑的学习曲线更陡——Studio的外观与WordPress差异足够大，总是需要一个培训周期。GROQ query language is expressive once you've spent a day with it, Sanity Studio is customisable in ways Contentful isn't, and the real-time collaboration is excellent. Pricing is more reasonable. The downside is that the learning curve for non-technical content editors is steeper — the Studio looks different enough from WordPress that there's always a training period.
Strapi
开源、自托管、运行免费。如果你有个客户不愿意付SaaS CMS费用但有服务器，Strapi值得考虑。管理面板还不错。但你得自己负责托管、升级和安全补丁。这不是小事。
Astro 与内容集合
对于内容较多但大多为静态的网站——文档、博客、营销网站——Astro 配合本地内容集合值得考虑。完全不需要 CMS。内容以 Markdown 或 MDX 文件的形式存储在代码库中。开发者喜欢这种方式。非技术编辑通常讨厌它。在采用这个方案之前，要了解你的用户。Astro with local content collections is worth considering. No CMS at all. Content lives as Markdown or MDX files in the repo. Developers love it. Non-technical editors usually hate it. Know your audience before going this route.
---
性能论证：数据实际说了什么
让我给你一个真实的基准数据，而不是关于速度的模糊说法。
Seahawk 的一个客户——一家 SaaS 公司，大约 80 个页面，中等流量——从托管的 WordPress 迁移到了 Next.js 配合 Sanity，部署在 Vercel 上。迁移前，Lighthouse 移动端得分在 62-68 左右。迁移后，稳定在 91-96。首字节时间从大约 420ms 降低到 80ms 以下。这不是边际改进。这是一个完全不同的产品。
但是——这很重要——他们有一名专职前端开发者、一个四人内容团队经过了 Sanity 培训，还有一份预算足以承担八周的构建周期。性能提升之所以明显，是因为让 headless 架构成功的条件都具备了。
Web Almanac 关于 CMS 性能的数据显示，headless 导向框架与传统耦合 CMS 之间的性能差距是真实存在的，但不是自动得到的。一个实现不当的 Next.js 网站完全可能性能低于一个配置得当的 WordPress 网站。仅有架构是不够的。Web Almanac's data on CMS performance shows that the performance gap between headless-oriented frameworks and traditional coupled CMSes is real but not automatic. A badly implemented Next.js site can absolutely underperform a well-configured WordPress site. Architecture alone doesn't save you.
---
做出决策：我实际使用的框架
当客户简报摆到我桌上，而我对是否适合采用无头架构有任何疑问时，我会在做出建议前过一遍五个问题。
- 内容是否需要在多个平台上展示？如果是，无头架构值得认真考虑。如果否，就失去了一个主要理由。 If yes, headless gets a serious look. If no, it loses a major justification.
- 内容团队的技术水平如何？非技术编辑在陌生的CMS中赶工期是个坏组合。 Non-technical editors on a tight deadline in an unfamiliar CMS is a bad combination.
- 预期的流量和性能要求是多少？月访客量在5万以下且使用合理的主机？WordPress能处理得很好。 Sub-50,000 monthly visitors on a reasonable host? WordPress handles it fine.
- 是否有专门的开发者负责后续维护？如果答案是"有问题时我们再找人"，那无头架构基础设施就是个隐患。 If the answer is "we'll call someone when it breaks," headless infrastructure is a liability.
- 实际预算是多少，包括第一年的运营费用？不只是开发成本。还有托管、CMS订阅、更新的开发者时间。总体拥有成本。 Not just the build. Hosting, CMS subscriptions, developer time for updates. Total cost of ownership.
如果第1、4、5个问题的答案对不上，我会推荐传统或混合方案，这样我能睡个好觉。
---
常见问题
无头WordPress是否比传统WordPress设置更好？
这完全取决于"更好"对你的具体项目意味着什么。对于多渠道交付、团队分离或高流量性能，无头WordPress——或用专业无头CMS替代WordPress——可以显著改善。对于一个小团队和适度流量的标准商业网站，配合好主题和适当缓存的传统WordPress更容易构建、成本更低、交付给客户也更简单。
无头架构总是意味着更好的性能吗？
不是。这个误解正在对项目预算造成真实伤害。从CDN提供的静态生成页面默认情况下速度更快，但配置不当的无头构建——包含未优化的图像、级联API请求和缺乏适当缓存——肯定会不如调优良好的WordPress网站。性能取决于执行，而不仅仅是架构。by default, but a poorly configured headless build with unoptimised images, waterfall API requests, and no proper caching can absolutely underperform a well-tuned WordPress site. Performance is about execution, not just architecture.
走向无头的最便宜方式是什么？
Strapi运行在每月5英镑的VPS上，结合部署在Vercel免费层的Astro或Next.js，可以以很低的月度成本实现功能性无头设置。你将以开发者时间来支付成本。没有什么真正免费——你只是在选择成本落在哪里。
无头构建相比传统CMS构建通常需要多长时间？
根据我的经验：类似项目在无头设置中需要的时间大约是WordPress的1.5倍到2.5倍，特别是对于团队的首个无头项目。随着团队对技术栈的熟悉，这个差距会缩小。在时间表和报价中诚实地考虑这一点——那些被告知"只需几周"的无头构建，最后花了四个月的客户不会再回头。
现在WordPress有了区块编辑器，无头架构在衰落吗？
不是，但低端的使用场景在缩小。古腾堡已经蚕食了一些以前需要无头架构的场景——交互式、组件驱动的内容体验在WordPress中现在无需解耦就更容易实现。在高端，对于大规模多渠道发布和电商，无头架构和以往一样相关。
---
Headless 不是身份象征。这是一种权衡——更多的灵活性、更多的复杂性、更高的成本，换取在特定情况下的实际收益。在做出承诺之前，先了解你的具体情况。我在开头提到的那个曼彻斯特电商客户最终迁移回了 Shopify 主题，并添加了一些自定义前端组件。他们将开发成本降低了 60%，加载时间也终于有所改善。有时候，老办法就是正确的办法。这没什么不好意思的。