前言：前几天，我刚聊过一个挺有争议的话题：都 AI 时代了，外贸工厂建独立站，到底还要不要用 WordPress？
最后得出了一个不太时髦的结论：
对于大多数以 Google SEO、产品展示和海外询盘为目标的外贸 B2B 企业，WordPress + AI 依然是值得优先考虑的方案。
结果话音刚落，PHP 就送来了一份大礼。
2026 年 10 月 21 日，PHP 官方发布紧急安全公告，披露了由 GPT-5.6Sol 发现的两个严重漏洞（不得不说，AI在安全领域的作用越来越占据主要位置了）：
CVE-2026-109618 和 CVE-2026-109619。
两个漏洞的 CVSS v4.0 评分都是 9.2。
在满足漏洞利用条件的情况下，攻击者甚至不需要登录，就可能在服务器上远程执行代码。
好家伙。
我这边刚说 WordPress 还能打，PHP 转头就给我表演了一个原地爆雷。
这不禁让我重新思考一个问题：
如果把安全性和未来五年的维护成本也算进去，WordPress 真的还是一个好选择吗？
或者说，换成 Next.js、Django，甚至直接让 AI 从零开发，是不是就能高枕无忧了？
这次，我决定不只看网站怎么建，还要看看网站建完以后，该怎么养。
PHP 出漏洞，为什么 WordPress 要跟着挨骂？
首先要弄明白一个事情。
WordPress 和 PHP 并不是同一个东西。
PHP 是编程语言和运行环境，WordPress 是使用 PHP 构建的内容管理系统。
简单理解，PHP 像发动机，WordPress 像汽车。
发动机发现严重问题，当然可能影响使用它的汽车。
但你不能因此认定汽车的方向盘、座椅、雨刷器全都有问题。
WordPress 也是一样。
一个 WordPress 网站，除了 WordPress 核心程序，还有 PHP、数据库、Web 服务器、主题、插件，以及各种自定义功能。
任何一个环节出现漏洞，都可能影响整个网站。
而这次的问题，偏偏就发生在 PHP 底层。
更麻烦的是，PHP 官方表示，部分攻击可以在应用程序代码运行之前触发。
这意味着，你就算把 WordPress 更新到最新，把 Elementor 检查了十八遍，也不能代替 PHP 本身的安全修复。
官方已经发布了修复版本，包括 PHP 8.2.35、8.3.36、8.4.27 和 8.5.12。
对于受影响的服务器，真正应该做的，是尽快升级到已修复版本。
网站安全从来不是某个软件单独负责的事情，而是整套技术架构共同承担的责任。
这件事让我想起之前比较独立站方案时，一个很容易被忽略的问题：
我们讨论了很多开发效率、SEO、网站性能和 AI 能力。
但网站交付之后的安全责任，究竟应该由谁承担？
换成 Next.js，就能跟漏洞说拜拜了吗？
在很多人的印象里，WordPress 是传统技术。
而 Next.js、React、Node.js，则代表着现代 Web 开发。
尤其是现在 AI 编程越来越成熟，使用 Codex 等工具，生成一套自定义网站已经不像以前那么困难。
于是就有一个很自然的想法：
既然 AI 都能写代码了，为什么还要使用 WordPress？
直接让 AI 写一套 Next.js 网站，不是更先进吗？
问题是：
AI 能降低代码的生产成本，但不能自动消除代码的安全风险。
我们看看几件真实发生过的事情。
React：CVSS 10.0，直接满分
2025 年 12 月，React 官方披露 CVE-2025-55182。
这是一个涉及 React Server Components 的远程代码执行漏洞，CVSS 3.1 评分达到 10.0。
部分使用相关服务端组件的 Next.js 应用也受到影响。
注意，这并不是说所有 React 网站都有这个漏洞。
但这个案例至少说明，现代前端技术同样可能出现严重安全问题。
Next.js：后台保安可能直接跳过检查
2025 年 3 月，Next.js 披露了 CVE-2025-29927。
这个漏洞在特定部署条件下，可能允许攻击者绕过 Middleware 中的权限检查。
想象一下：
你的网站后台门口站着一个保安，负责检查通行证。
结果攻击者发现，只要使用某种特殊方式，就能让保安直接跳过检查。
保安还在。
门也在。
就是检查这一步没了。
Django：Python 阵营也不是世外桃源
2025 年 11 月，Django 官方修复了 CVE-2025-64459。
这是一个在特定参数使用条件下可能引发 SQL 注入的高危漏洞。
所以，换成 Python，也没有自动获得安全免疫资格。
这几个案例的影响条件各不相同，评分版本也不完全一致，不能简单按数字给技术栈排安全名次。
但有一点很明确：
PHP 有漏洞，不代表 PHP 独有问题；Next.js、React 和 Django 同样需要持续安装安全补丁。
原来用 WordPress，担心 PHP、插件和主题。
现在换成 Next.js，开始担心 NPM 依赖、React、Node.js 和各种第三方服务。
从一个坑跳出来，发现隔壁是另一个坑。
只是坑的 UI 更现代了一点。
WordPress 一年上万个漏洞，这还能用吗？
如果只看漏洞数量，WordPress 的确比较容易让人心惊肉跳。
根据 Patchstack 发布的《State of WordPress Security in 2026》，2025 年 WordPress 生态发现了 11,334 个新漏洞。
比上一年增长约 42%。
其中，约 91% 来自插件，约 9% 来自主题，WordPress 核心只占极少数。
一万多个。
乍一看，我都怀疑 WordPress 是不是用漏洞拼起来的乐高积木。
但这里有一个统计陷阱。
这些漏洞来自整个 WordPress 生态，包括大量不同的插件和主题。
并不是说你安装一个 WordPress，服务器就自动附赠一万多个漏洞。
同样，也不能拿 WordPress 整个生态的漏洞数量，直接去比较 Django 或 Next.js 核心框架披露的漏洞数。
Next.js 背后还有 NPM 生态。
Django 背后也有 Python 第三方软件包。
此外，公开披露的漏洞数量还受到软件使用规模、安全研究投入和披露机制等因素影响。
真正需要关心的，是自己的网站安装了哪些组件，其中是否存在可被利用的漏洞，以及漏洞出现后多久能够修复。
所以，我并不认为 WordPress 最大的问题是它使用 PHP。
更需要警惕的是：
一个普通企业官网，明明只需要展示产品、发文章、收询盘，却安装了几十个来源不明的插件。
里面还有几个插件三年没更新。
这就像装修一套房子。
本来两个房间、一个客厅就够了。
结果非要加十几个地下室、八条秘密通道、三座观光电梯。
最后连自己都不知道哪里还有门。
很多时候，真正增加安全成本的，是不必要的系统复杂度。
现在重新看，四种独立站方案谁更省心？
上一篇讨论独立站技术选型时，我主要把方案分为四类。
现在把长期安全维护也考虑进去，我发现原来的判断还需要补充一些条件。
WordPress + AI：成熟，但需要有人管理
这仍然是我比较倾向于用于普通 B2B 外贸企业官网的方案。
AI 可以协助完成需求分析、页面规划、文案编写、部分主题开发和自定义功能。
WordPress 则负责内容管理、媒体、用户权限和网站运营。
优势是成熟。
客户更新产品、发布文章，不需要每次都找开发人员。
安全维护方面，WordPress 核心、插件和主题都有相对成熟的更新机制，很多日常任务可以标准化。
但前提是：
插件不能无限安装，服务器不能几年不升级，自定义代码也不能写完就扔。
如果没有持续维护，成熟生态同样可能变成安全负担。
AI + 定制开发：自由度很高，责任也很大
如果企业需要复杂交互、业务管理、客户账户、ERP 集成，那么 Next.js、Django 等技术就有自己的优势。
但是，一旦选择定制开发，就意味着网站的很多功能需要由自己负责。
包括代码依赖、身份认证、接口安全、权限管理和系统升级。
AI 可以把原来需要几天写完的代码，缩短到几个小时。
但五年后框架版本需要升级时，谁来处理兼容性？
第三方依赖出现高危漏洞时，谁来排查？
原来的开发人员离职以后，谁能接手？
这些问题都不能靠一句“代码是 AI 写的”解决。
我越来越觉得：
AI 把开发门槛降低了，却让长期维护能力变得更加重要。
混合架构：灵活，但不等于自动安全
比如 WordPress 负责内容管理，Next.js 或 Astro 负责前端展示。
这种 Headless CMS 架构可以兼顾内容管理体验和前端定制能力。
但它也意味着需要维护 CMS、API、前端项目和部署流程。
如果网站真的需要高度定制，这些复杂度可以是值得的。
但如果只是一个普通工厂官网，还没有复杂的业务需求，就把系统拆成好几部分……
我只能说：
原本一口锅就能煮熟的饭，非要建一条自动化食品生产线。
最后可能饭没做快多少，设备维修人员倒是多招了几个。
网站建完以后，养五年到底要花多少钱？
这里才是我真正想讨论的问题。
我们选择技术的时候，很容易只关注开发费用。
WordPress 建站多少钱？
Next.js 开发多少钱？
用 AI 能省多少人工？
但企业官网不是上线当天就结束生命周期的东西。
它可能要持续运行三年、五年，甚至更长时间。
在这个过程中，操作系统、PHP、Node.js、Python、CMS、第三方依赖都会持续更新。
所以我做一个简单的假设测算。
假设是同样规模的 B2B 企业官网，具备正常的安全维护流程。
技术人员综合人工成本按每小时 200 元计算。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
先强调，这些数字不是行业平均价格，也不是任何技术栈的固定运维费用。
只是为了讨论成本差异建立的情景模型。
不包含初次开发费用、托管平台订阅、重大安全事故和新功能开发。
如果 Next.js 项目有完善的自动化测试和托管部署，实际维护成本可能很低。
如果 WordPress 使用大量不可靠插件，维护成本也可能非常高。
而 AI + Astro 的静态化方案，甚至可能比表格中的几种动态网站架构更省心。
所以真正值得比较的，并不是技术名字，而是具体项目要运行多少组件、依赖多少服务，以及每次升级需要投入多少人工。
对于普通外贸企业官网，WordPress 的一大优势，是常规安全维护比较容易形成标准化流程。
当一家建站公司需要同时维护几十个、上百个客户网站时，标准化本身就是非常重要的成本优势。
而如果每个项目都采用不同的 AI 自定义代码、不同的依赖版本、不同的后台架构……
那未来维护时，恐怕每个网站都能给开发人员带来一次新的冒险体验。
比选择 WordPress 还是 Next.js 更重要的事情
经过这次漏洞事件，我反而更加确定了一件事：
对于专业建站公司，真正需要建立的，不只是设计和开发流程，还应该包括安全维护流程。
比如：
-
网站交付前，明确运行环境、插件及第三方依赖的版本。 -
控制不必要的插件和接口，减少攻击面。 -
建立定期备份、漏洞监控和恢复测试机制。 -
严重漏洞出现后，明确由谁检查、谁更新、谁验证。 -
将自定义表单、数据追踪、文件上传和权限管理纳入安全检查。 -
对客户提供持续维护服务，而不只是一次性交付网站。
尤其是最后一点，我认为很值得认真考虑。
过去很多企业建站的商业模式是：
客户付钱，设计网站，开发网站，上线，收尾款。
然后双方愉快地失去联系。
三年后客户突然发来消息：
“我们的网站打不开了。”
打开后台一看。
PHP 版本古老得像考古现场，十几个插件等待更新，原来的主题作者已经消失在互联网的风中。
这个时候才开始谈安全维护，多少有点晚了。
对企业来说，网站并不是一个一次性装修项目。
它更像一项需要长期运营的数字资产。
对建站公司来说，安全维护也完全可以形成长期、持续的服务业务。
而且这种业务的价值，不只是帮客户点一下“更新”按钮。
真正有价值的是提前识别风险、快速响应漏洞、控制更新影响，并且在发生问题时能够恢复业务。
那么，2026 年做独立站，我还推荐 WordPress 吗？
推荐。
但我要给之前的结论增加一个前提：
对于普通 B2B 外贸营销网站，WordPress + AI 仍然值得优先考虑，但必须建立持续的安全维护机制。
如果网站简单、以静态内容为主，AI + Astro 可以是更轻量化的选择。
如果业务高度复杂，Next.js、Django 等定制开发方案当然有价值。
如果既需要成熟 CMS，又需要高度定制的前端体验，混合架构同样值得评估。
至于哪一种绝对更安全？
目前没有足够统一的公开数据，可以直接计算出这些完整技术栈的真实入侵率，并给它们排出一个绝对名次。
安全性最终取决于实际架构、代码质量、部署环境，以及持续维护能力。
所以，我对 AI 建站的看法也逐渐变得更加完整。
以前我们很关心：
AI 能不能把网站做出来？
现在看来，真正的问题应该是：
AI 做出来的网站，五年以后谁来维护？
这才是 AI 建站越来越普及之后，企业真正需要考虑的长期问题。
回到上一篇文章的那句话：
没有最好的技术，只有更适合业务的技术。网站是为了接订单，不是为了参加前端技术选美大赛。
现在我想再补上一句：
网站不仅要能接订单，还得保证五年后，它依然有能力继续接订单。
否则，建站的时候像超级跑车，上线时各种炫技。
过了三年，换个机油都找不到维修师傅。
这就不是技术先进了。
这是给客户送了一台限量版电子古董。
延伸阅读：
都 AI 时代了，外贸工厂建独立站，到底还要不要用 WordPress？
上一篇主要比较 WordPress + AI、AI + Astro、AI + 定制开发和混合架构，讨论外贸企业应该如何结合 SEO、获客能力、开发效率及长期成本选择技术方案。
这一篇则补上另一个经常被忽略的维度：网站上线之后的安全和维护责任。
2026年了，我发现SEO最该优化的，居然不是关键词！
为什么我用的AI总是废话连篇？试试这几种方法让你的AI变强！
做了10年独立站，我受够了那些“反人类”的SEO工具，干脆自己造了一个