2021年，一个曼彻斯特的中等规模电商品牌的客户给我打电话，他们有大约40,000个SKU，多个区域门店，非常恼火。他们在一个无头Shopify构建上花了18个月和180,000英镑，配合Next.js前端，结果页面加载时间比他们之前使用的Shopify主题还慢。他们的开发团队从1个承包商扩展到了4个人。内容编辑器需要开发人员在场才能发布一篇博文。Next.js front end, and their page load times were 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.
关键要点：当你真正需要多个前端，或者单体架构无法达到的性能时，才采用无头架构；一个配有优质主题的 WordPress 网站胜过三个开发者维护一个你根本不需要的技术栈。Go headless when you genuinely need multiple front ends or performance a monolith cannot hit; one WordPress site with a good theme beats three developers maintaining a stack you did not need.
无头架构曾被向他们推销为未来。从技术角度讲，确实是这样。但没人告诉他们运营它的实际成本会有多高。
在Seahawk Media，我参与过12,000多个网站的构建或监督。无头架构在其中大约8-10%的项目上是正确的选择。剩下的90%？那会是一场灾难，费用昂贵，上线慢，维护痛苦。这篇文章是关于在你已经写支票之前，就知道你的项目属于哪一类。
---
"无头"在实践中实际意味着什么
我们先快速理清定义。传统CMS，WordPress、Squarespace，无论什么，都是把内容管理后端与前端展现层耦合在一起的。它们本地相互通信。无头架构则解耦了它们。你的CMS（Contentful、Sanity、Strapi、WordPress以无头模式运行）变成了一个纯内容API。你的前端，Next.js、Nuxt、Astro、SvelteKit，无论你喜欢什么，获取那个内容并以它想要的方式渲染它。WordPress, Squarespace, whatever, couples the content management back end to the front-end presentation layer. They talk to each other natively. Headless decouples them. Your CMS (Contentful, Sanity, Strapi, WordPress in headless mode) becomes a pure content API. Your front end, Next.js, Nuxt, Astro, SvelteKit, whatever you fancy, fetches that content and renders it however it wants.
想法很简单。复杂性在其他地方层层出现。
实际在项目中出现的技术栈
实际上，当有人说"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页面根本无法达到的，无论你的服务器优化得多好。当你面对每月数百万页面浏览量时，那些毫秒会累积成有意义的收入差异。谷歌的研究已多次证实了加载速度和转化率之间的相关性，这不是理论。 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不错，编辑UI也还可以。定价是痛点——免费层对小项目确实有用，但一旦超过限制，你就在看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转到了Vercel上部署的Next.js配Sanity。迁移前，Lighthouse移动端得分在62-68之间。之后，始终稳定在91-96。首字节时间从大约420毫秒下降到80毫秒以下。这不是边际改进。这是一个完全不同的产品。
但这很重要，他们有一个专职前端开发者、一个四人内容团队经过了Sanity培训、以及一个可以承受八周构建周期的预算。性能收益之所以真实，是因为让无头方案运作的条件已经到位。
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.
走向无头的最便宜方式是什么？
在 £5/月的 VPS 上运行 Strapi，配合 Astro 或 Next.js 部署在 Vercel 免费层，可以用很低的月度成本获得一个可用的无头架构。你只是把成本转移到开发人员工时上。没有真正免费的东西，你只是在选择成本落在哪里。
无头构建相比传统CMS构建通常需要多长时间？
根据我的经验：相比 WordPress，无头架构的同等项目大约需要 1.5 倍到 2.5 倍的时间才能完成，尤其是对于团队的第一个无头项目。随着团队对技术栈的熟悉度增加，这个差距会缩小。要实事求是地把这一点纳入时间表和报价中。那些被告知"只需几周"就能完成无头建设的客户，结果花了四个月，通常不会再回头。
现在WordPress有了区块编辑器，无头架构在衰落吗？
不是。但使用场景在低端市场有所萎缩。Gutenberg 侵蚀了一些曾经需要无头架构的场景，互动的、基于组件的内容体验现在在 WordPress 中无需解耦就能实现。在高端市场，对于大规模多渠道发布和电商业务，无头架构的相关性仍然和以往一样强。
---
无头架构不是身份象征。它是一种权衡，用更多的灵活性、更多的复杂性、更多的成本，来换取在特定场景中获得真实收益。在承诺之前要了解情况。我在开头提到的曼彻斯特电商客户最终迁回到 Shopify 主题加一些自定义前端组件。他们把开发开销降低了 60%，加载时间也终于改善了。有时旧方法就是正确方法。这没什么丢脸的。