一个客户在 2021 年给我打了电话——房产公司，预算还不错，刚解雇了前一家代理公司。任务很简单：重建他们的房源门户。他们离职的开发者花了八个月来搭建一个定制的 Next.js 应用。在演示中看起来很棒。但团队里没有任何一个人可以在没有拉取请求和部署流程的情况下更新它。管理房源的房产中介用谷歌表格作为临时方案。
我用 Advanced Custom Fields Pro 在大约六周内用 WordPress 重建了它。他们从那以后就一直自己管理它。Advanced Custom Fields Proin about six weeks. They've been managing it themselves ever since.
这个故事不是反对 Next.js 的论点。这是一个反对在理解问题之前就选择工具的论点。我也做过相反的事——给一个需要真正的 React 驱动应用的客户交付了 WordPress 多站点，然后看着它在十八个月后在压力下开始吱吱嘎嘎作响。
在 Seahawk Media 构建了 5000+ 个网站后，我不再关心哪个框架"赢"。我关心的是哪个能交付、性能好、不会在周日晚上 11 点回来缠着你。Seahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
两种技术目前的真实状况
WordPress 驱动全球约 43% 的网站。这个数字被引用得太频繁了，已经失去了意义，但仔细想想。43%。这不是遗留惯性——这是网络效应、插件生态、托管基础设施，以及二十年来积累在全球每个共享服务器上的制度知识。
与此同时，Next.js 已经成为生产应用的主流 React 框架。Vercel 2023 年的使用数据显示它每个月处理数千亿次请求。Next.js 13 推出的 App Router 改变了人们对服务器组件的看法——是的，它也破坏了许多 2023 年前发布的教程，这仍然在各地的 Discord 服务器引起困惑。
但这里有个关键点：这两种技术并不像 Twitter 争论中那样是真正的竞争对手。WordPress 是一个带主题层的 CMS。Next.js 是一个带可选 CMS 集成的 React 框架。当你具体考虑需求时，它们的真实能力范围的韦恩图几乎没有重叠。
---
WordPress 真正无可匹敌的地方
由非开发者管理的内容密集型网站
我直言不讳。如果你的客户有营销团队、内容管理员，或任何需要在不接触代码的情况下发布内容的人——WordPress 几乎总是正确答案。Gutenberg 编辑器，不管你是喜欢还是讨厌它（自 2018 年以来我与它的关系很复杂），为非技术用户提供了一个真正可用的块状编辑体验。anyonewho needs to publish without touching code — WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
React 生态中的任何东西都无法与 WordPress 的开箱即用编辑体验相提并论。Sanity.io 有漂亮的工作室，Contentful 对结构化内容很扎实——但两者都没有 WordPress 拥有的插件生态或搜索引擎熟悉度。普通的营销新员工之前用过 WordPress。他们没用过无头 CMS。
插件生态深度
WooCommerce、Yoast、Gravity Forms、WP Rocket、ACF Pro。这些不仅仅是插件——它们是拥有各自生态系统的完整平台。当Seahawk为一个商品目录适中的客户（比如不超过5,000个SKU）做电商项目时，WooCommerce配合Kinsta或WP Engine的得当托管就能完全胜任。我说的是缓存后的亚2秒加载时间、完整的库存管理、弃购车恢复、Stripe集成——所有这些都能在一个下午内配置好。Kinstaor WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration — all configured in an afternoon.
用自定义Next.js构建配合Shopify或无头商务层来复制这些功能？你要花上数周的开发时间，加上大多数中小企业客户无法承担的持续维护成本。
预算和时间的现实
说实话，大多数项目的预算都达不到定制React应用的水平。一个用Kadence或Blocksy这样的高级主题构建的设计精良的WordPress网站，加上用于自定义数据结构的ACF和用于性能优化的WP Rocket，可以在两到四周内交付，几乎任何人都能维护。这不是局限——这是务实。
---
Next.js真正发挥其复杂性优势的地方
交互性和应用逻辑
早在2022年，Seahawk有一个金融科技项目——一个信用分析公司的仪表板。实时数据流、复杂过滤、基于角色的访问控制、与三个不同数据提供商的API集成。我用了大约两小时考虑无头WordPress，最后承认它根本不是正确的工具。我们用Next.js配合NextAuth.js进行身份验证和React Query进行数据获取来构建它。它仍在运行，仍然很快，代码库是客户的内部团队能够实际参与的东西。
WordPress在技术上可以做类似应用的事情。但每当我试图将它推向真正动态的领域时——想想有条件逻辑的多步表单馈送到外部API、实时仪表板、任何需要细粒度客户端状态的东西——我最终都是在与架构对抗而不是与它一起工作。
无插件依赖的规模化性能
使用 Next.js 的静态站点生成（SSG）或增量静态再生（ISR）可以生成速度快得几乎令人尴尬的页面。无需缓存插件。无需调整 WP Rocket 的配置。这些页面就是...静态 HTML，在需要的地方进行水合。
Vercel 关于 ISR 的文档对该机制解释得很好，但实际的含义是这样的：一个拥有 50,000 篇文章的新闻出版物 Next.js 网站可以按计划重新验证单个页面，而无需重建整个网站。这是真正强大的功能，WordPress 只能通过片段缓存来近似实现。explains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
开发者体验和团队构成
如果你的代理商拥有一个 React 原生开发团队，WordPress 开发确实有一个陡峭的学习曲线，通常被低估了。PHP、WordPress 模板层级、钩子架构、functions.php 的兔子洞——不是很难，但确实不同。我曾聘用过才华横溢的 JS 开发者，他们看着 WordPress 主题代码库感到迷茫了前两周。functions.phprabbit hole — it's not hard, but itisdifferent. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
反过来说，如果你的团队生活在 TypeScript 和 React 中，一个带有 Contentful 或 Sanity 这样的无头 CMS 的 Next.js 项目会是一个更舒适的环境。代码是可测试的，类型是明确的，通过 Vercel 或 Netlify 的部署流程确实很好。
---
无头 WordPress 的中间地带（及其真正的问题）
许多代理商已经采用"无头 WordPress"作为折衷方案——WordPress 作为 CMS 后端，Next.js 作为前端。这个方案听起来完美无缺。编辑团队保留他们熟悉的界面；开发者获得现代前端栈。
实际上？在特定情况下确实有用，在其他情况下则是真正的麻烦。
好的情况：goodcases:
- 大型发布平台，其中编辑工作流程不可协商，但前端性能也是硬性要求
- 已在 WordPress 基础设施中投入的组织，希望现代化前端而无需重新培训内容团队
- 具有复杂内容关系的网站，从 ACF 的数据建模中受益，但需要 React 来处理展示层
实际的问题：actual problems:
- WPGraphQL 非常出色，但在 WordPress 环境中调试 GraphQL 查询性能很痛苦。你在增加一个复杂性层，这可能会伤害你。is excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- 编辑人员的预览功能——在 Next.js 前端上查看草稿文章——是持续的错误源。我在多个项目中为此浪费了数天。
- 托管两个独立系统意味着两个单点故障，两套基础设施成本，以及两个部署管道需要维护。
- 实时功能仍然很尴尬。你无法从 WordPress REST API 中获得 WebSocket，除非进行大量额外工作。
Headless WordPress 不是一个神奇的中间地带。它是一个有自己权衡的第三个选项，只有当具体要求真正证明复杂性是合理的时，它才有意义。
---
我如何做决定（我的真实检查清单）
经历了足够多的项目后，我把这归纳为第二次客户通话前要问的一套快速问题。
倾向于选择 WordPress 当：
- 客户或其团队需要独立管理内容
- 项目主要是内容和营销页面（即使很复杂）
- 预算在 £20K 以下，时间在八周以内
- 需要电商功能，但产品目录在约 10,000 个以下
- 客户已经在用 WordPress，迁移没有实际意义
倾向于选择 Next.js 当：
- 项目有大量交互或类应用程序的需求
- 团队主要是 JS/React 开发人员
- 你需要对渲染策略进行细粒度控制（每路由的 SSG、SSR、ISR）
- 前端设计系统是定制的且由 React 组件驱动
- 有真实的理由与现代无头 CMS（如 Sanity 或 Contentful）集成
- 长期来看，客户希望由内部 JS 开发人员自己拥有和扩展前端
以及一些红旗，无论你倾向于哪个方向都应该让你暂停：red flagsthat should make you pause regardless of which direction you're leaning:
- 客户因为读到 Next.js "更现代"就要求使用 Next.js — 这不是一个需求
- 当项目确实需要应用逻辑时，因为"更容易"就选择 WordPress
- 任何人使用"未来保障"这个说法作为理由，但没有说明未来实际上需要什么
---
性能：让我们使用真实数据
这就是对话经常出问题的地方。人们把 Lighthouse 分数当成了全部故事。
一个优化得当的 WordPress 网站——体面的主机、WP Rocket 或 FlyingPress、WebP 图像、构建得当的主题——通常在 PageSpeed Insights 上得分 90 分以上。Seahawk 持续交付 95 分以上的 WordPress 网站。这不是魔法；只是正确的配置。
一个配置糟糕的 Next.js 应用，到处都是客户端数据获取、未优化的图像，没有适当的缓存策略，得分会在 50 分左右。我见过这样的情况。
"快速的 WordPress 网站"和"快速的 Next.js 网站"之间的差距远比框架传教士所暗示的要小得多。Google 自己的 Core Web Vitals 研究表明，原始技术的重要性远低于实现质量。大多数性能不佳网站的瓶颈是图像、阻止渲染的资源和服务器响应时间——这些都不是 WordPress 或 Next.js 固有的问题。Google's own Core Web Vitals researchshows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times — none of which are inherently WordPress or Next.js problems.
Next.js 真正提供的是对性能的更多控制权。你可以按路由做出精确决策，决定如何获取数据以及何时渲染页面。但控制权只有在你正确使用它时才能帮助你。more controlover performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
SEO：WordPress 有生态优势，而不是固有优势
这是我必须经常纠正的一个误解：WordPress 在 SEO 上并非固有更优。具有适当服务端渲染的 Next.js 应用完全可被 Google 爬取。<Head> 组件、通过 next-sitemap 生成站点地图、通过 JSON-LD 的结构化数据——这些都是可以实现的。<Head>component, sitemap generation vianext-sitemap, structured data via JSON-LD — it's all achievable.
WordPress 拥有的是 Yoast SEO 或 Rank Math，它们为非技术用户提供了一个可视化界面来管理元标题、描述、规范 URL 和 schema 标记。这是一个编辑工作流优势，而不是技术优势。
如果网站由理解元标签和结构化数据的开发者管理，Next.js SEO 不难实现。如果网站需要 SEO 顾问或市场营销经理在不提工单的情况下调整页面标题——那就选 WordPress。
---
常见问题
WordPress 不是过时的吗，不是被现代框架取代吗？
自至少 2014 年我第一次严肃地听到这个论点以来，WordPress 就一直在"被取代"。这没有发生过，我也不预期它会发生。问题不在于 WordPress 是否现代化——而在于它是否解决了你面临的问题。对于绝大多数网站来说，它确实解决了。Automattic 继续在 Gutenberg 和全站编辑体验上大力投资。它在演进，只是不是以让 Twitter 上的人兴奋的方式。
能用 WordPress 作为后端，React 作为前端吗？
能，这就是无头 WordPress，我上面已经讲过权衡。简单来说：用 WPGraphQL 或 REST API 提供内容，用 Next.js 构建前端。能行。但也增加了复杂性。只有当需求真正要求这样做时才这样做，别因为听起来在架构上有趣就这样做。
相比 WordPress，Next.js 网站需要多长时间来构建？
真的取决于范围，但对于一个可比的营销网站，Next.js 通常需要比初次交付多花 40–60% 的时间。你要从头写组件，搭建设计系统，集成 CMS，配置部署。有高级主题和 ACF 的 WordPress 能让你更快地走得更远。Next.js 在长期可扩展性和开发者体验上收回时间投资——前提是团队构成能证明这样做是合理的。
那 Astro、Remix 或其他框架呢？
值得了解。Astro 特别有趣，适合内容密集型静态网站，我一直在 Seahawk 的小项目中试验它。Remix 有一个很有吸引力的数据加载模型。但这两者都不如 WordPress 的生态成熟度或客户熟悉度，也不如 Next.js 的企业采用率。对于大多数代理商的决策来说，现在仍然是在 WordPress 和 Next.js 之间做选择，其他一切都是小众考虑。
我应该总是向客户推荐"更好的"技术选择吗？
不应该。客户团队无法维护的最佳技术选择，比他们能真正使用的次优技术选择更糟。我已经用血泪教训学过多次了。要交付对相关人员有效的东西，而不仅仅是架构图看起来完美。
---
真正的技能不是懂 WordPress 或懂 Next.js。而是知道什么时候用哪一个——并且诚实地面对自己和客户，根据他们的实际情况做决定，而不是你的偏好。
那个 2021 年的房产客户？仍然在用 WordPress。仍然自己管理他们的房源。没有我周日晚上的紧急电话。