2021 年一个客户找我——房产公司，预算不错，刚刚炒了之前的代理机构。任务很简单：重建他们的房源门户。他们之前的开发者花了八个月搭建一个定制 Next.js 应用。看起来在演示中很棒。但团队里任何人都没办法单独更新它，必须走 pull request 和部署流程。负责管理房源的房产经纪人用 Google Sheet 作为变通方案。
关键要点：当编辑人员需要自主权且内容每天都变化时，WordPress 赢；当站点是一个有工程支撑的产品时，Next.js 赢。团队来决定，不是框架。WordPress wins when editors need autonomy and content changes daily; Next.js wins when the site is a product with engineering behind it. The team decides, not the framework.
我用 WordPress 和 Advanced Custom Fields Pro 在大约六周内重建了它。自那以后，他们一直在自己管理。WordPress with Advanced Custom Fields Pro in about six weeks. They've been managing it themselves ever since.
那个故事不是在抨击 Next.js。而是在反对你还没理解问题就选择工具。我也做过相反的事——给一个客户交付 WordPress 多站点，而他们其实需要一个真正的 React 驱动应用，结果十八个月后眼睁睁看着它在压力下崩溃。
在 Seahawk Media 建立了 12,000+ 个网站后，我不再关心哪个框架"赢了"。我关心的是哪个能交付、性能如何、以及不会在周日晚上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% 的站点。这个数字被引用得这么频繁以至于失去了意义，但停下来想一秒钟。四十三个百分点。这不是遗留惯性——这是网络效应、插件生态、托管基础设施，以及二十年来的机构知识烙印在地球上每一台共享服务器上。
Next.js 则成了生产应用的主流 React 框架。Vercel 2023 年的使用数据显示它每月处理数千亿请求。Next.js 13 引入的 App Router 改变了人们对服务端组件的认知——没错，它也破坏了 2023 年之前发布的大量教程，在各个 Discord 服务器里仍在造成混淆。Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components -- and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
但这里有个关键点：这两种技术并不像 Twitter 争论中那样是真正的竞争对手。WordPress 是一个带主题层的 CMS。Next.js 是一个带可选 CMS 集成的 React 框架。当你具体考虑需求时，它们的真实能力范围的韦恩图几乎没有重叠。
---
WordPress 真正无可匹敌的地方
由非开发者管理的内容密集型网站
我直说。如果你的客户有市场团队、内容经理，或者任何需要在不接触代码的情况下发布内容的人——WordPress 几乎总是正确答案。Gutenberg 编辑器，爱也好恨也好（我自 2018 年以来与它的关系一直很复杂），为非技术用户提供了一个真正有效的基于块的编辑体验。anyone who 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 有漂亮的 studio，Contentful 对结构化内容很可靠——但都不具备 WordPress 的插件生态和搜索引擎熟悉度。你招来的普通市场营销人员用过 WordPress。他们没用过无头 CMS。Sanity.io has a beautiful studio, Contentful is solid for structured content -- but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
插件生态深度
WooCommerce、Yoast、Gravity Forms、WP Rocket、ACF Pro。这些不只是插件——它们是拥有自己生态的完整平台。当 Seahawk 为一个目录规模适中的客户（比如 SKU 数在 5,000 以下）做电商项目时，WooCommerce 配合 Kinsta 或 WP Engine 上体面的托管设置工作得很好。我们说的是缓存后的亚 2 秒加载时间、完整库存管理、弃购恢复、Stripe 集成——全部在下午内配置完成。Kinsta or 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应用。一个精心搭建的WordPress网站，配合Kadence或Blocksy这样的高级主题，使用ACF来处理自定义数据结构，再加上WP Rocket优化性能，可以在两到四周内交付，而且几乎任何人都能维护。这不是局限——这是务实。
---
Next.js真正发挥其复杂性优势的地方
交互性和应用逻辑
早在2022年，Seahawk做过一个金融科技项目——一个信用分析公司的仪表板。实时数据流、复杂的筛选逻辑、基于角色的访问控制、与三个不同数据提供商的API集成。我看了大约两小时的headless 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模板层级、Hook架构、functions.php无底洞——不算难，但确实不同。我雇过一些才华横溢的JS开发者，他们看到WordPress主题代码库后，前两周都感到迷茫。functions.php rabbit hole -- it's not hard, but it is different. 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 的中间地带（及其真正的问题）
很多代理商都选择了"headless WordPress"作为折中方案——WordPress作为CMS后端，Next.js作为前端。这个提议听起来完美无缺。编辑团队保留他们熟悉的界面；开发者则获得了现代化的前端栈。
实际上？在特定情况下确实有用，在其他情况下则是真正的麻烦。
好的情况：good cases:
- 大型发布平台，其中编辑工作流程不可协商，但前端性能也是硬性要求
- 已在 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前端上查看草稿文章——总是bug的来源。我在多个项目上为此浪费过很多天。
- 托管两个独立系统意味着两个单点故障，两套基础设施成本，以及两个部署管道需要维护。
- 实时功能仍然很尴尬。你无法从 WordPress REST API 中获得 WebSocket，除非进行大量额外工作。
Headless WordPress 不是一个神奇的中间地带。它是一个有自己权衡的第三个选项，只有当具体要求真正证明复杂性是合理的时，它才有意义。
---
我如何做决定（我的真实检查清单）
经历了足够多的项目后，我把这归纳为第二次客户通话前要问的一套快速问题。
倾向于选择 WordPress 当：
- 客户或其团队需要独立管理内容
- 项目主要是内容和营销页面（即使很复杂）
- 预算在 £20K 以下，时间在八周以内
- 需要电商功能，但产品目录在约 10,000 个以下
- 客户已经在用 WordPress，迁移没有实际意义
倾向于选择 Next.js 当：
- 项目有大量交互或类应用程序的需求
- 团队主要是 JS/React 开发人员
- 你需要对渲染策略进行细粒度控制（每路由的 SSG、SSR、ISR）
- 前端设计系统是定制的且由 React 组件驱动
- 有真实的理由与现代无头 CMS（如 Sanity 或 Contentful）集成
- 长期来看，客户希望由内部 JS 开发人员自己拥有和扩展前端
还有一些红旗，无论你倾向于哪个方向，都应该让你停下来思考：red flags that should make you pause regardless of which direction you're leaning:
- 一个客户要求用Next.js，因为他们读到它"更现代"——这不是真正的需求。
- 当项目确实需要应用逻辑时，因为"更容易"就选择 WordPress
- 任何人使用"未来保障"这个说法作为理由，但没有说明未来实际上需要什么
---
性能：让我们使用真实数据
这就是对话经常出问题的地方。人们把 Lighthouse 分数当成了全部故事。
一个优化良好的WordPress网站——合适的主机、WP Rocket或FlyingPress、WebP图片、构建得当的主题——经常在PageSpeed Insights上得分90以上。Seahawk一直稳定交付95以上的WordPress网站。这不是魔法；只是正确的配置。
一个配置糟糕的 Next.js 应用，到处都是客户端数据获取、未优化的图像，没有适当的缓存策略，得分会在 50 分左右。我见过这样的情况。
"快速的WordPress网站"和"快速的Next.js网站"之间的差距，远比框架倡导者暗示的要小。Google自己的核心Web指标研究表明，源技术远不如实现质量重要。大多数性能不佳网站的瓶颈是图片、渲染阻塞资源和服务器响应时间——这些都不是WordPress或Next.js固有的问题。Google's own Core Web Vitals research shows 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 control over 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生成的sitemap、通过JSON-LD的结构化数据——这些都是可以实现的。<Head>component, sitemap generation via next-sitemap, structured data via JSON-LD -- it's all achievable.
WordPress 拥有的是 Yoast SEO 或 Rank Math，它们为非技术用户提供了一个可视化界面来管理元标题、描述、规范 URL 和 schema 标记。这是一个编辑工作流优势，而不是技术优势。
如果网站由了解元标签和结构化数据的开发者管理，Next.js SEO 的实现难度并不比 WordPress 高。如果网站需要 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。仍然自己管理他们的房源。没有我周日晚上的紧急电话。