2021年，一个曼彻斯特的中等规模电商品牌的客户给我打电话，他们有大约40,000个SKU，多个区域门店，非常恼火。他们在一个无头Shopify构建上花了18个月和180,000英镑，配合Next.js前端，结果页面加载时间比他们之前使用的Shopify主题还慢。他们的开发团队从1个承包商扩展到了4个人。内容编辑器需要开发人员在场才能发布一篇博文。
关键要点：当你真正需要多个前端，或者单体架构无法达到的性能时，才采用无头架构；一个配有优质主题的 WordPress 网站胜过三个开发者维护一个你根本不需要的技术栈。
无头架构曾被向他们推销为未来。从技术角度讲，确实是这样。但没人告诉他们运营它的实际成本会有多高。
在Seahawk Media，我参与过12,000多个网站的构建或监督。无头架构在其中大约8-10%的项目上是正确的选择。剩下的90%？那会是一场灾难，费用昂贵，上线慢，维护痛苦。这篇文章是关于在你已经写支票之前，就知道你的项目属于哪一类。
---
"无头"在实践中实际意味着什么
我们先快速理清定义。传统CMS，WordPress、Squarespace，无论什么，都是把内容管理后端与前端展现层耦合在一起的。它们本地相互通信。无头架构则解耦了它们。你的CMS（Contentful、Sanity、Strapi、WordPress以无头模式运行）变成了一个纯内容API。你的前端，Next.js、Nuxt、Astro、SvelteKit，无论你喜欢什么，获取那个内容并以它想要的方式渲染它。
想法很简单。复杂性在其他地方层层出现。
实际在项目中出现的技术栈
实际上，当有人说"Headless"时，他们通常指的是以下几种组合中的一种：
- Contentful 或 Sanity 作为 CMS，通过 REST 或 GraphQL 提供 JSON
- 前端使用 Next.js，采用静态生成（SSG）或服务器端渲染（SSR）
- Vercel 或 Netlify 进行部署和边缘函数
- 如果涉及电商，则使用 Shopify Storefront API 或 BigCommerce
- 某种版本的 Algolia 用于搜索，因为原生搜索选项通常很糟
这些都是独立的供应商关系、独立的账单行项目，以及独立的可能在周五凌晨 2 点出问题的东西。
---
采用 Headless 架构的真正理由
这里的问题是，确实有真实的、正当的理由来这样做。我不是在否定这种架构。我只是厌倦了它被不加区别地应用。
多渠道内容分发是最有力的论证。如果同一内容需要出现在网站、手机应用、信息亭显示器和智能电视界面上，耦合CMS就变得真正麻烦。一个API被全部四个界面查询？那才真正有意义。Seahawk有一个迪拜的酒店集团客户，那种有面向公众的网站、内部员工应用和整个物业数字显示屏的度假村集团。单个Sanity实例支撑所有这一切。那是正确的选择，没有疑问。
真正大规模下的性能是第二个正当的论证。从CDN边缘提供的静态生成页面的速度是PHP渲染的WordPress页面根本无法达到的，无论你的服务器优化得多好。当你面对每月数百万页面浏览量时，那些毫秒会累积成有意义的收入差异。谷歌的研究已多次证实了加载速度和转化率之间的相关性，这不是理论。
团队分离也很重要，但仅限于足够大的组织有独立的前端和后端团队。如果你的内容团队是一个 20 人的市场营销部门，想要独立于工程团队运作，CMS 和前端之间的干净 API 契约可以让双方在互不阻碍的情况下工作。
那三个案例？确实值得复杂性成本。其他一切通常都是被装扮成架构的一厢情愿。
---
Headless 何时只是昂贵的过度设计
伦敦会计师事务所的五页宣传册网站不需要 Headless 架构。有一个开发者做顾问的 200 产品 WooCommerce 店铺也不需要。
我经常看到这个错误，特别是来自刚刚发现Next.js并想把它用在一切地方的开发人员。（我自己在2019年也犯过这个错误，为一个小慈善客户建立了一个无头博客，花了三天配置webhook来在新文章发布时触发Netlify重建，还向他们收费，现在只要有什么坏掉他们还是会打电话给我。）问题是无头将运维复杂性从CMS转移到了基础设施。WordPress自己更新自己。你定制的Next.js + Contentful管道不会。
无头架构通常成本大于回报的具体场景:
- 小型内容团队，如果一两个人管理所有内容，一个像WordPress这样的真正耦合CMS的编辑体验确实比无头CMS要好。预览环境更难。内联编辑消失了。所见即所得被削弱了。
- 紧张的预算，一个真正的无头构建的开发成本是可比WordPress构建的2-3倍，持续维护也更高。如果预算是限制因素，那笔钱几乎总是在别处发挥更大的作用。
- 内容更新频繁，静态生成意味着需要构建时间。一家新闻发布商每天发布50篇文章，不会想每次都等8分钟来进行整个网站的完整重建。（是的，增量静态再生成有帮助。但它也带来了自己的复杂性。）
- 没有专职DevOps，得有人负责部署管道、CDN配置、环境变量、预览URL。在小团队中，这个人通常就是那个什么都在做的开发者。
---
WordPress 无头折中方案
我想反驳的一点是"传统 WordPress"和"带有独立 CMS 的完全无头"之间的假二分法。有一个中间路径对某一类项目来说效果非常好。
将WordPress用作无头后端，使用WP REST API或WPGraphQL，让你获得客户已经熟悉的内容管理体验（老实说，大多数客户都懂WordPress），同时结合现代前端的灵活性。你不用付费给Contentful。你不用重新培训任何人。编辑团队继续用Gutenberg。前端可以是任何适合项目的框架。
过去四年我在大概30-40个项目上用过这个模式。它特别适合那些在WordPress中已有大量现成内容库、不想迁移但又想要React前端来提高性能或交互性的营销网站。代价是WPGraphQL插件维护可能会比较麻烦，而且你仍然在运行PHP服务器，没有完全摆脱WordPress托管。
---
选择无头CMS：实用对比
不同的无头CMS并不相同，而且当人们对前端框架感到兴奋时，这个选择的重要性远比他们承认的要大。
Contentful
企业级选项。API扎实，SDK不错，编辑UI也还可以。定价是痛点——免费层对小项目确实有用，但一旦超过限制，你就在看300美元/月以上的价格，而这还没做任何有趣的东西。对于预算充足的项目和需要适当角色和权限工作流的组织，我会选择Contentful。
Sanity
我个人在大多数中端无头项目上的最爱。GROQ查询语言一旦花一天时间学习就很强大，Sanity Studio的可定制性超过Contentful，实时协作也很出色。定价更合理。缺点是非技术内容编辑的学习曲线更陡峭，Studio看起来跟WordPress差异大到总需要一个培训期。
Strapi
开源、自托管、运行免费。如果你有个客户不愿意付SaaS CMS费用但有服务器，Strapi值得考虑。管理面板还不错。但你得自己负责托管、升级和安全补丁。这不是小事。
Astro 与内容集合
对于内容繁重、主要是静态的网站、文档、博客、营销网站，Astro配合本地内容集合值得考虑。完全不用CMS。内容以Markdown或MDX文件的形式存储在代码仓库中。开发者喜欢。非技术编辑通常讨厌。在选这条路前要了解你的用户。
---
性能论证：数据实际说了什么
让我给你一个真实的基准数据，而不是关于速度的模糊说法。
一个Seahawk客户，一家SaaS公司，大约80个页面，流量中等，从托管WordPress转到了Vercel上部署的Next.js配Sanity。迁移前，Lighthouse移动端得分在62-68之间。之后，始终稳定在91-96。首字节时间从大约420毫秒下降到80毫秒以下。这不是边际改进。这是一个完全不同的产品。
但这很重要，他们有一个专职前端开发者、一个四人内容团队经过了Sanity培训、以及一个可以承受八周构建周期的预算。性能收益之所以真实，是因为让无头方案运作的条件已经到位。
Web Almanac 关于 CMS 性能的数据显示，headless 导向框架与传统耦合 CMS 之间的性能差距是真实存在的，但不是自动得到的。一个实现不当的 Next.js 网站完全可能性能低于一个配置得当的 WordPress 网站。仅有架构是不够的。
---
做出决策：我实际使用的框架
当客户简报摆到我桌上，而我对是否适合采用无头架构有任何疑问时，我会在做出建议前过一遍五个问题。
- 内容是否需要在多个平台上展示？如果是，无头架构值得认真考虑。如果否，就失去了一个主要理由。
- 内容团队的技术水平如何？非技术编辑在陌生的CMS中赶工期是个坏组合。
- 预期的流量和性能要求是多少？月访客量在5万以下且使用合理的主机？WordPress能处理得很好。
- 是否有专门的开发者负责后续维护？如果答案是"有问题时我们再找人"，那无头架构基础设施就是个隐患。
- 实际预算是多少，包括第一年的运营费用？不只是开发成本。还有托管、CMS订阅、更新的开发者时间。总体拥有成本。
如果第1、4、5个问题的答案对不上，我会推荐传统或混合方案，这样我能睡个好觉。
---
常见问题
无头WordPress是否比传统WordPress设置更好？
完全取决于对你的具体项目来说"更好"意味着什么。对于多渠道交付、团队分离或高流量下的性能，无头WordPress或用专门无头CMS替换WordPress可以显著改进。对于有小团队和中等流量的标准商业网站，传统WordPress配合好主题和适当缓存更容易构建、运行成本更低、交付给客户也更简单。
无头架构总是意味着更好的性能吗？
不是。这个误解正在对项目预算造成真实伤害。从CDN提供的静态生成页面默认情况下速度更快，但配置不当的无头构建——包含未优化的图像、级联API请求和缺乏适当缓存——肯定会不如调优良好的WordPress网站。性能取决于执行，而不仅仅是架构。
走向无头的最便宜方式是什么？
在 £5/月的 VPS 上运行 Strapi，配合 Astro 或 Next.js 部署在 Vercel 免费层，可以用很低的月度成本获得一个可用的无头架构。你只是把成本转移到开发人员工时上。没有真正免费的东西，你只是在选择成本落在哪里。
无头构建相比传统CMS构建通常需要多长时间？
根据我的经验：相比 WordPress，无头架构的同等项目大约需要 1.5 倍到 2.5 倍的时间才能完成，尤其是对于团队的第一个无头项目。随着团队对技术栈的熟悉度增加，这个差距会缩小。要实事求是地把这一点纳入时间表和报价中。那些被告知"只需几周"就能完成无头建设的客户，结果花了四个月，通常不会再回头。
现在WordPress有了区块编辑器，无头架构在衰落吗？
不是。但使用场景在低端市场有所萎缩。Gutenberg 侵蚀了一些曾经需要无头架构的场景，互动的、基于组件的内容体验现在在 WordPress 中无需解耦就能实现。在高端市场，对于大规模多渠道发布和电商业务，无头架构的相关性仍然和以往一样强。
---
无头架构不是身份象征。它是一种权衡，用更多的灵活性、更多的复杂性、更多的成本，来换取在特定场景中获得真实收益。在承诺之前要了解情况。我在开头提到的曼彻斯特电商客户最终迁回到 Shopify 主题加一些自定义前端组件。他们把开发开销降低了 60%，加载时间也终于改善了。有时旧方法就是正确方法。这没什么丢脸的。