TL;DR：先看结论

最近不少坛友在问：预算有限，1核1G 的 VPS（Virtual Private Server，虚拟专用服务器）到底能不能跑 WordPress？还是必须咬牙上 2核2G？这篇实测就是为了帮助大家用数据而不是感觉做决定：我把两台同机房、同系统的机器跑了同一套 WordPress 压测，结论先放在前面：纯博客加全页缓存，1核1G 带 2 到 10 个并发没问题；一旦动态请求变多、插件超过 20 个或者要跑 WooCommerce，1G 内存就是硬瓶颈，2核2G 才是起点。下面是完整过程和数据，欢迎对照自己的站点规模判断。

测试环境与方法

两台机器来自同一服务商的美国机房，系统统一 Debian 12，避免虚拟化和内核差异干扰结论。WordPress 6.x、PHP 8.2、MariaDB 10.11，主题和插件完全一致，测试前各做一轮系统更新并重启。

压测工具用 wrk 和 sysbench 组合：前者模拟真实 HTTP 并发，后者专测 CPU 与内存压力。站点分两种状态各测三轮取中位数——裸 WordPress（无缓存插件）和装了全页缓存的 WordPress，这样能看出缓存对入门配置的“救命”程度。测试统一在晚高峰前完成，减少线路抖动对数据的污染。

基础性能：CPU 与内存差距有多大

先看跑分数据。sysbench 单线程 CPU 测试里，1核1G 组 events per second 稳定在 950 上下，2核2G 组单线程 960、双线程叠加后接近 1900——也就是说纯计算吞吐量基本是翻倍的关系。两台机器主频相同，2核的优势在于 PHP 进程和 MariaDB 查询可以分到两个核上跑，而不是排队等一个核。

内存这边差距更值得注意。1G 内存装完 LNMP 一套，加上系统本身占用，开机空闲状态只剩大约 300 MB 可用；2G 机器则有约 1.2 GB 余量。MariaDB 默认配置在 1G 机器上必须调低 innodb_buffer_pool_size 才不触发 OOM，后面调优清单会展开。

裸 WordPress 压测：没有缓存时的真实上限

裸站（关闭缓存）用 wrk 从本机压 30 秒，每个请求都完整走一遍 PHP 解析加数据库查询，模拟最坏情况：

数据很直观：低并发下 2核2G 的吞吐接近 1核1G 的 1.7 倍；并发拉到 50 时，1核1G 的延迟飙到 15 秒量级，基本“假死”，而 2核2G 虽吃力，5 秒左右的延迟还没到彻底不可用。造成这种差距的核心原因不是 CPU 跑分，而是内存：1G 机器在高压下频繁进入 swap（交换分区，用磁盘临时顶替内存的机制），一次页面渲染要来回换页，速度自然断崖式下跌。TTFB（Time To First Byte，首字节时间，衡量服务器响应速度的关键指标）方面，并发 2 时两组都在 200 毫秒附近，说明小流量下入门配置并不亏待访客；真正的分水岭在并发 10 以后。

开全页缓存后：入门配置的“第二春”

装上全页缓存并预生成首页和文章页后，情况完全反转。静态命中的请求不再经过 PHP 和数据库，wrk 复测结果：1核1G 在并发 50 时仍能跑出 480 QPS、平均延迟 102 毫秒；2核2G 同条件约 520 QPS、延迟 94 毫秒。两者的差距缩小到个位数百分比——因为缓存命中后瓶颈从“算得快不快”变成了“网络吐得快不快”，而带宽（网络每秒可传输的数据量）两台机器是一样的。

这也解释了坛子里一个常见现象：同样是 1核1G，有人喊卡有人喊真香，区别往往就在有没有把缓存配对。内容以文章页为主、登录用户少的站点，全页缓存能把 90% 以上的请求挡在 PHP 门外，入门配置撑得住日均几千 PV。需要留心缓存过期策略：发布新文章后缓存批量重建，1核1G 会短暂吃满 CPU，通常几十秒内恢复，属正常现象而非宕机。

数据库与后台操作：数据不会说谎的地方

前台快不快看缓存，后台顺不顺畅看的就是实打实的配置了。导入 80 MB 测试数据集（约 1200 篇文章）时，2核2G 用时 2 分 40 秒，1核1G 用了 5 分 50 秒，差了一倍多。文章超过 1000 篇、插件 20 个以上时，1核1G 的后台列表页要 2.5 秒，2核2G 控制在 1.2 秒内——经常编辑内容的站长会天天感受到这种差距。

另一项隐藏开销是备份与更新。核心加插件更新要解包、写库、清缓存，1核1G 此时内存水位会冲到 85% 以上，若同时再跑每日备份，OOM（Out Of Memory，内存耗尽后被系统强制杀进程）概率明显上升。实测中把更新和备份错开两小时执行后，稳定性立刻恢复——这类调度细节对 1G 机器是必修课，对 2G 机器可以粗放些。另外，如果测试数据是从旧站搬来的，迁移本身也吃资源，可参考之前整理的 WordPress 网站迁移工具实测，选低峰期操作会省心很多。

换成 WooCommerce：入门配置的分界线

纯内容站之外，很多坛友的真实需求是小商店。装上 WooCommerce、导入 100 个商品后复测，结论就残酷多了：购物车和结账页面无法使用全页缓存，每个请求都要实时算价格、查库存。并发 5 时 1核1G 的结账接口延迟已经到 1800 毫秒，并发 10 出现首波超时；2核2G 在并发 10 时延迟 890 毫秒，坚持到并发 30 才开始明显劣化。

我的判断标准很简单：日均订单 20 单以内、商品 200 个以内的轻量店铺，2核2G 起步；1核1G 跑 WooCommerce 不是不行，而是要接受高峰期结账变慢的现实——电商场景里结账每慢一秒都在真实地流失订单，这钱不建议省。想省预算的话，砍掉冗余插件、控制商品图体积，比降配置更有效。

1核1G 想跑得稳：这五件事必须做

实测过程中 1核1G 组踩过的坑，整理成一份调优清单，照做能少走弯路：

• PHP-FPM 子进程数压到 2 个：默认配置在 1G 内存下会开 5 个以上子进程，每个吃 60 MB 左右，内存直接见底；改成 pm.max_children=2 后峰值内存稳定在 70% 以下。
• MariaDB 调低 innodb_buffer_pool_size 到 128M：默认值按大内存机器设计，1G 机器不改必炸；改完后数据库查询延迟反而因为少了换页而下降。
• 必须装全页缓存并预生成：这是 1核1G 能撑住并发的唯一大招，实测能把吞吐拉高近 60 倍。
• 更新、备份、爬虫类插件的任务错峰执行：全部挤在同一时段等于自己给自己压测。
• 上 swap 监控告警：swap 用量一旦超过 100 MB 就该警惕，等到 OOM 才发现就晚了。

这份清单里的面板操作细节，之前在 宝塔面板一键部署 WordPress 全攻略 里有完整流程，新手可以直接照着做。

总结：钱该花在哪，数据已经给答案

总结一下两组数据：1核1G 和 2核2G 的差距，在纯静态内容场景下可以被缓存抹平，在动态请求场景下则是实打实的一倍以上。入门配置不是不能用，而是要用在对的地方——更新频率低的文章站、个人博客、企业官网，1核1G 配好缓存后体验并不输； WooCommerce、多插件、多作者的站点，1G 内存从第一天起就是天花板。

给三条落地建议：第一，如果你的站点日均 PV 在 5000 以下且以文章页为主，1核1G 够用，把省下的预算花在 线路与速度优化 上对访客体感的提升更大；第二，一旦站点出现登录用户多、动态查询多的迹象，直接上 2核2G，不要在 1G 机器上反复折腾换插件，时间是最大的成本；第三，无论哪档配置，选服务商时优先看同价位的 CPU 主频和内存超售策略，这两个参数对 WordPress 的实际影响远比营销页上的“高性能”三个字大。在类似价位段，Hostease 的入门 VPS 在中文支持和 CN2 线路上的表现可以纳入备选，配合本文调优清单，入门配置也能跑出主流体验。如果你需要进一步确认自己的站点该选哪档，建议把本文的测试方法直接搬到你的机器上跑一轮，真实数据通常比参数页更有说服力。