为什么 MODX 用户应该在 2026 年迁移到 Next.js：诚实的看法
我自从 Evolution 时代就开始在 MODX 上建站。我写过自定义代码片段、跟模板变量（TV）较过劲（不是电视机），还在无数 CMS 辩论中为 MODX 辩护过。所以当我说这不是批评文章时，请相信我。这是来自一个真正热爱这个平台的人的警钟。
但问题在于：网页开发世界已经向前发展了，而 MODX 没有跟上。社区在萎缩，发布周期慢得令人难以忍受，人才库干涸的速度比七月的水坑还快。如果你在 2026 年仍在 MODX 上运行生产站点，你需要认真考虑你的退出策略。对于大多数团队来说，那个出口指向 Next.js。
让我为你详细说明原因——坦诚相待，没有炒作。
目录
- 2026 年 MODX 的现状
- MODX 做对的事（现在仍在做）
- 不能再忽视的问题
- 为什么 Next.js 是自然的迁移目标
- 迁移路径：MODX 到 Next.js
- 选择无头 CMS 替代 MODX
- 真实性能收益：迁移前后对比
- 你会错过什么（以及你不会错过什么）
- 成本对比：运行 MODX vs Next.js
- 常见问题
2026 年 MODX 的现状
让我们诚实地看看数字。MODX 3.x 已经发布一段时间了，但采用率一直都很……不温不火。MODX 论坛曾经热火朝天，现在每周只有寥寥几篇帖子。官方 GitHub 存储库显示提交活动越来越稀少。比较一下 2018 年或 2019 年，那时社区还在奋力推进。
2026 年初 BuiltWith 数据估计 MODX 支持大约 0.3% 的 CMS 检测网站，而 2021 年约为 0.7%。WordPress 仍然主导市场，占 ~62%，而像 Next.js 为基础的网站（通常配合无头 CMS）正以大约 40% 的年增长率增长。
MODX 市场（以前的 Extras 存储库）数个月内没有发布过有意义的新扩展。许多流行的扩展都没有维护或仅部分兼容 MODX 3.x。当生态系统停止生产时，这不是红旗——这是白旗。
我不是在说 MODX 已死。它仍然有效。你的站点仍在运行。但"仍然有效"是网页开发中的危险之地。
MODX 做对的事（现在仍在做）
在我继续抱怨之前，先给应有的掌声。MODX 做对了几件大多数 CMS 仍然搞错的事情：
真正的内容灵活性
MODX 从不强制你进入"文章和页面"范式。模板变量、代码块和代码片段在"结构化内容"成为流行语多年前就给了你真正的内容建模自由度。你可以构建任何东西。
干净输出
MODX 不注入自己的标记。没有神秘的 CSS 类，没有你没有要求的包装 div。你的 HTML 就是你的 HTML。对于关心工艺的前端开发者来说，这是一次启示。
开发者友好的主题设计
没有要学的主题系统，没有要记忆的模板层级。你写模板。就这样。代码块是可重用的部分。代码片段是 PHP 逻辑。简单的心智模型，强大的结果。
标签语法
随便怎么说 [[*pagetitle]] 和 [[!MySnippet]] 吧——一旦你学会了，你就可以快速构建复杂页面。带有 ! 未缓存标志的缓存层设计优雅。
这些优势实际上使 MODX 开发者成为现代无头架构的绝佳候选人。如果你已经在结构化内容和基于组件的模板中思考，你已经走到 Next.js 的一半了。
不能再忽视的问题
现在我必须坦率一些。
安全隐患
MODX 3.x 解决了许多历史漏洞，但运行任何带有公开管理面板的 PHP 单体应用都存在固有的风险。2025 年，我们看到至少两个影响 MODX 安装的严重 CVE，补丁花了几周才发布。随着安全团队的萎缩，响应时间不会改善。
相比之下，部署在 Vercel 或 Netlify 上的 Next.js 网站——根本没有服务器可攻击。没有管理面板可暴力破解。没有 PHP 可利用。攻击面本质上更小。
人才危机
尝试在 2026 年雇一个 MODX 开发者。去试试。发布职位公告，然后听听蟋蟀叫声。开发者池已经迁移到 React、Next.js 和现代 JavaScript 框架。甚至 PHP 人才都转向了 Laravel，而不是 MODX。
这不是理论问题。我跟过一些机构，他们有 MODX 网站，他们真的找不到开发者来维护。当原始开发者离职时，该网站就成了一个负债。
PHP 8.x 兼容性问题
MODX 3.x 可以在 PHP 8 上运行，但许多扩展不能。如果你构建的站点依赖第三方代码片段或插件，升级 PHP 通常会破坏东西。你最终会被固定在较旧的 PHP 版本上，这又回到了安全问题。
没有现代开发体验
没有热模块重新加载。没有基于组件的架构。没有 TypeScript 支持。没有内置图像优化。没有边缘渲染。没有 ISR。我还可以继续。
MODX 的开发工作流基本上是：在管理器中编辑文件或代码块（或通过同步工具在你的 IDE 中编辑），清除缓存，刷新浏览器。它有效，但与现代 DX 相比很慢。
性能上限
MODX 可以很快——我已经在它上面构建过响应时间不到 2 秒的网站。但达到那里需要大量优化：整页缓存、CDN 设置、数据库调优和谨慎的代码片段架构。Next.js 本质上会给你现成的亚秒级性能和静态生成。你在 MODX 上为性能而战；在 Next.js 上，你必须争取搞砸它。
为什么 Next.js 是自然的迁移目标
你可能会问：为什么不是 WordPress？为什么不是 Astro？为什么不是静态网站生成器？
都是有效选项，但 Next.js 对大多数 MODX 迁移来说都是最佳选择。原因如下：
渲染灵活性镜像 MODX 思维
MODX 开发者已经理解不同页面需要不同的缓存策略。在 MODX 中，你会将代码片段标记为缓存或未缓存。在 Next.js 中，你为每个页面选择静态网站生成（SSG）、增量静态再生（ISR）和服务器端渲染（SSR）。同样的概念，更好的执行。
组件架构替代代码块
MODX 代码块是可重用的 HTML 部分。React 组件是具有内置逻辑的可重用 UI 部分。如果你一直在编写像 [[!$header]] 和 [[!$footer]] 这样的代码块，你已经在组件中思考。你只是还没有使用 props。
API 路由替代代码片段
MODX 代码片段处理服务器端逻辑——表单处理、API 调用、自定义查询。Next.js API 路由（或 Next.js 14+ 中的服务器操作）做同样的事情，但使用更好的工具和测试支持的 JavaScript/TypeScript。
对于考虑替代方案的团队，Astro 值得评估内容密集型网站，这些网站不需要太多互动。但如果你需要动态功能、身份验证体验或复杂的数据获取，Next.js 是更强的选择。
迁移路径：MODX 到 Next.js
让我们更实际一些。MODX 到 Next.js 迁移实际上是如何运作的。
步骤 1：审计你的内容模型
映射每个 MODX 模板、模板变量和资源类型。这成为你在选择的任何无头 CMS 中的内容模型。文档化一切：
## 资源：博客文章
- pagetitle → title (文本)
- longtitle → seo_title (文本)
- content → body (富文本)
- TV: hero_image → hero_image (媒体)
- TV: author → author (引用)
- TV: category → category (分类)
步骤 2：导出你的内容
MODX 没有很好的导出工具。你可能需要写一个自定义代码片段或脚本，查询 modx_site_content 和你的 TV 表，然后输出 JSON：
<?php
// 快速而肮脏的 MODX 内容导出
$resources = $modx->getCollection('modResource', [
'published' => 1,
'deleted' => 0
]);
$output = [];
foreach ($resources as $resource) {
$output[] = [
'id' => $resource->get('id'),
'title' => $resource->get('pagetitle'),
'slug' => $resource->get('alias'),
'content' => $resource->get('content'),
'template' => $resource->get('template'),
'tvs' => $resource->getTemplateVars(),
'parent' => $resource->get('parent'),
'publishedon' => $resource->get('publishedon'),
];
}
header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);
然后为你的目标 CMS 写导入脚本。这是枯燥的工作，但只需一次性付出。
步骤 3：构建你的 Next.js 前端
从 create-next-app 开始，将你的模板构建为页面组件。你的 MODX 模板 → 页面布局映射可能如下所示：
| MODX 概念 | Next.js 等价物 |
|---|---|
| 模板 | 布局组件 |
| 代码块 | React 组件 |
| 代码片段 | 服务器操作 / API 路由 |
| 模板变量 | CMS 字段 |
| 资源 | 页面 / 内容条目 |
[[*field]] 标签 |
Props / 数据获取 |
| 插件（事件钩子） | 中间件 |
[[!uncached]] |
SSR / 动态渲染 |
[[cached]] |
SSG / ISR |
步骤 4：处理 URL 重定向
这是人们搞砸的地方。每个旧的 MODX URL 都需要一个 301 重定向到它的新 Next.js 等价物。构建一个重定向映射并将其添加到 next.config.js：
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... 数百条，由你的导出生成
]
},
}
不要跳过这个。你的 SEO 取决于它。
步骤 5：并行运行 2-4 周
在你现有的 MODX 网站旁部署 Next.js。测试一切。检查分析。验证表单有效。然后切换 DNS。
选择无头 CMS 替代 MODX
Next.js 是你的前端，但你仍然需要某个地方来管理内容。以下是流行选项对 MODX 难民的比较：
| CMS | MODX 开发者学习曲线 | 内容建模 | 定价（2026） | 自托管选项 |
|---|---|---|---|---|
| Sanity | 中等 | 优秀（代码定义的模式） | 免费层，然后 $15/用户/月 | 否（仅云） |
| Strapi | 低 | 良好（基于 UI） | 免费（自托管）、云服务从 $29/月 | 是 |
| Contentful | 中等 | 良好 | 免费层，然后 $300/月 | 否 |
| Payload CMS | 低 | 优秀（代码定义） | 免费（自托管）、云服务从 $50/月 | 是 |
| Directus | 低 | 灵活 | 免费（自托管）、云服务从 $99/月 | 是 |
如果你喜欢 MODX 的灵活性和自托管功能，Payload CMS 或 Strapi 会感到最熟悉。如果你想要最佳开发体验且不介意仅云端，Sanity 很难被击败。
我们通过我们的无头 CMS 开发实践与所有这些进行了广泛的工作，正确的选择真的取决于你团队的舒适度和预算。
真实性能收益：迁移前后对比
我在 2025 年底将一个中等规模的 MODX 网站（大约 400 个页面，博客 + 服务 + 作品集）迁移到 Next.js 和 Sanity。以下是实际数字：
| 指标 | MODX（优化） | Vercel 上的 Next.js | 改进 |
|---|---|---|---|
| Lighthouse 性能 | 72 | 98 | +36% |
| 最大内容绘制 | 2.8s | 0.9s | -68% |
| 首字节时间 | 680ms | 45ms | -93% |
| 核心网页指标通过 | 部分 | 完全通过 | ✅ |
| 构建/部署时间 | 手动 FTP | 42秒自动部署 | 天壤之别 |
| 月度托管成本 | $45/月（VPS） | $0（Vercel 免费层） | -100% |
仅 TTFB 的改进就是惊人的。MODX 必须启动 PHP、连接到 MySQL、运行代码片段、组装代码块并提供响应——即使有缓存。一个静态生成的 Next.js 页面从 CDN 边缘节点在毫秒内提供。
你会错过什么（以及你不会错过什么）
你会错过
- 管理器 UI：MODX 的管理面板对内容编辑者来说真的直观。大多数无头 CMS 管理面板都有学习曲线。
- 上下文编辑：在你看到它呈现的地方编辑内容。大多数无头设置需要在 CMS 和预览之间切换。（Sanity 的演示工具和 Payload 的实时预览正在缩小这个差距。）
- 简洁性：一个服务器、一个数据库、一个代码库。这里面有美。无头堆栈有更多的活动部分。
- 社区氛围：MODX 社区虽然很小，但非常紧密团结，真的很有帮助。
你不会错过
- 缓存清除：无尽的缓存清除-刷新循环。
- TV 管理：通过 UI 为每个字段创建和管理模板变量。
- 数据库焦虑：当你的 MySQL 连接在流量激增时达到最大值时的那种沉没感。
- FTP 部署：或任何你用来推送更改的手动过程。
- 插件事件调试：尝试弄清楚哪个插件在什么时候以什么顺序触发。
成本对比：运行 MODX vs Next.js
让我们对总拥有成本而不仅仅是托管成本坦率一些。
| 成本类别 | MODX（年） | Next.js + 无头 CMS（年） |
|---|---|---|
| 托管 | $540-$1,200（VPS/共享） | $0-$240（Vercel/Netlify） |
| CMS 许可 | $0（开源） | $0-$3,600（取决于 CMS） |
| SSL 证书 | $0-$100 | $0（包含） |
| CDN | $0-$600 | $0（包含） |
| 安全监控 | $200-$500 | 最小（没有服务器） |
| 服务器维护 | $500-$2,000（时间或外包） | $0 |
| 开发者小时费率 | $75-$120（稀缺人才） | $100-$175（充足人才） |
| 总计（不含开发时间） | $1,240-$4,400 | $0-$3,840 |
变数是开发者费率。MODX 开发者每小时便宜如果你能找到他们的话。但稀缺会随时间推高费率，你经常被卡住了无论谁可用而不是选择最佳契合。
如果你正在评估你特定情况的迁移成本，我们在这里分解了我们的定价方法——我们对这些项目实际成本是透明的。
常见问题
典型的 MODX 到 Next.js 迁移需要多长时间？
对于有 100-500 个页面的网站，预计 6-10 周需要专业团队。内容建模和迁移需要约 2 周，构建 Next.js 前端需要 3-5 周，QA/测试/重定向填补了其余部分。较大的网站（具有复杂的自定义代码片段或繁重的电子商务集成）可能需要 12-16 周。最大的变数是需要重新编写多少自定义 PHP 逻辑。
我能保持我的 MODX 管理面板而只为前端使用 Next.js 吗？
在技术上，可以——你可以在 MODX 中构建一个 REST API 层并用 Next.js 消费它。但这给了你两者中最坏的：你仍然维护 PHP 服务器、MySQL 数据库和所有安全关注事项，同时也维护一个单独的前端。除非你有非常具体的原因，最好将内容迁移到一个专用的无头 CMS。
迁移期间我会失去 SEO 排名吗？
不会，如果你正确处理重定向。关键步骤是：尽可能保持相同的 URL 结构，为任何改变的 URL 设置 301 重定向，保持你的元数据完整，并在启动后向 Google Search Console 提交更新的站点地图。我们迁移的大多数网站在 4-8 周内看到排名改进，原因是更好的核心网页指标分数。
MODX 网站如何使用 FormIt 表单和复杂工作流？
表单是迁移的较棘手部分之一。FormIt 在一个包中处理验证、电子邮件发送、钩子和垃圾邮件防护。在 Next.js 中，你通常将服务器操作用于处理、Zod 用于验证和像 Resend 或 SendGrid 这样的服务用于电子邮件传递。它更明确但也更可测试和可靠。
对于简单的宣传册网站，Next.js 是否过度？
也许。如果你的 MODX 网站字面上只有 10 个静态页面和一个联系表单，Astro 可能更适合——它默认不装载零 JavaScript 并且更简单地设置。但如果有任何可能你稍后需要动态功能、身份验证或复杂的数据获取，从 Next.js 开始会让你避免另一次迁移。
我的 MODX 扩展和自定义代码片段怎么办？
它们需要被重建。没有自动转换。自定义代码片段在 Next.js 中成为 API 路由或服务器操作。像 Gallery、Articles 或 MIGX 这样的扩展被替换为你无头 CMS 的原生功能（通常更好）。像 Foxy 或 SimpleCart 这样的电子商务扩展会被 Shopify 的 Storefront API、Snipcart 或 Medusa 所取代。在你的迁移时间表中明确计划这个工作量。
我如何说服非技术利益相关者批准这次迁移？
关注三件他们关心的事情：风险、成本和结果。风险：MODX 社区萎缩意味着在紧急情况下寻找开发者变得每年都更难。成本：服务器维护和安全补丁不是免费的，即使 CMS 许可是免费的。结果：向他们展示核心网页指标比较，解释 Google 如何使用页面速度作为排名因素。如果他们的竞争对手在一秒以下加载而他们在 3 秒，这是一个业务问题。
我能逐步迁移还是必须一次性全部迁移？
增量迁移是可能的，使用反向代理设置——你从 Next.js 提供新页面，并将旧页面路由到你的 MODX 服务器。我们用 nginx 配置完成过这个，其中特定路径被代理到旧服务器，而其他一切都去新的 Next.js 部署。它增加了复杂性，但对于有数百个页面的网站，它让你在数周或数月内分阶段迁移，而不是做冒险的大爆炸切割。
如果你在 MODX 网站上坐着并感到我描述的痛点，最好的开始规划时间是现在。不是因为天要塌下来，而是因为在压力下完成的迁移——在安全漏洞之后、在你的开发者离职之后、在 PHP 版本到达生命周期结束之后——总是比计划好的更昂贵和更有压力。如果你想讨论你的具体情况，请联系我们。我们已经经历这么多次了，知道陷阱在哪里。