用1核CPU和1GB内存的云主机部署WordPress是否可行？-云技术博客

直接给结论：理论上可行，但生产环境强烈不推荐，体验会非常差。

如果你只是用来自己写写博客、做测试、或者给内部小团队用，那是可以跑起来的。但如果想面向公网用户访问，尤其是稍微有点并发或者图片资源较多的情况，1核1G 的云服务器（ECS/CVM/轻量应用服务器等）基本就是“坐牢”。

下面从技术角度拆解一下为什么这么说，以及如果非要这么干该怎么优化。

WordPress 不是一个静态 HTML 页面，它是一个基于 PHP + MySQL/MariaDB 的动态 CMS。这两个组件对内存和 CPU 的消耗是联动的：

PHP-FPM 进程开销：每个请求都会启动或复用 PHP 进程。1GB 内存里，操作系统内核本身就要占去 200-300MB，剩下的给数据库和 PHP 用。一旦并发稍高，PHP 进程数增加，内存瞬间打满，系统开始 Swap（交换分区）。
MySQL/MariaDB 的压力：默认配置的 MySQL 在低配机器上非常吃内存。哪怕你只开了几个查询，如果索引没建好或者查询慢，CPU 占用率会飙升到 100%，导致页面加载超时。
缓存缺失：没有足够的内存来支撑有效的 OPcache 和对象缓存（如 Redis），每次请求都要重新解析 PHP 代码并查询数据库，IO 延迟极高。

在 1核1G 环境下部署 WordPress，你大概率会遇到以下场景：

如果你确实只有这个配置，且业务量很小（比如个人日记型博客，日均 PV < 100），可以通过以下手段极限优化：

推荐方案：使用宝塔面板（BT Panel）的一键部署 LNMP 环境，或者直接使用云厂商提供的“WordPress 镜像”（通常已经预装了优化过的 Nginx + PHP + MySQL）。
关键点：确保使用的是 Nginx 而不是 Apache。Apache 在处理并发时比 Nginx 更耗内存。

调整 my.cnf 配置：

innodb_buffer_pool_size = 64M  # 默认可能是 128M 或更高，必须调低，否则直接 OOM
max_connections = 50           # 限制最大连接数，防止被拖垮
key_buffer_size = 16M

启用 Query Cache（注意：MySQL 8.0+ 已移除，MariaDB 可用）：虽然现代观点认为 Query Cache 有争议，但在极低配单机上，它能减少重复查询的 CPU 消耗。

页面缓存：安装 WP Super Cache 或 W3 Total Cache。设置“页面压缩”和“浏览器缓存”，让大部分请求直接由 Nginx 返回静态 HTML，绕过 PHP 和数据库。
对象缓存：如果可能，申请一个免费的 Redis 实例（很多云厂商对新用户有免费额度），或者在本地运行一个极简的 Redis 服务（需额外分配 ~50MB 内存）。如果连 Redis 都装不下，就全靠页面缓存硬扛。

主题：只用最轻量的主题，如 GeneratePress、Astra 或 Twenty Twenty-One。避开 Elementor、Divi 等重型构建器。
插件：能不用就不用。关闭所有不必要的功能（如自动备份、SEO 分析、社交分享按钮等）。建议只保留：缓存插件 + 安全插件（如 Wordfence Lite，但要小心其资源占用）。

Swap 分区：虽然 Swap 慢，但在内存耗尽时它是最后一道防线。建议创建 1-2GB 的 Swap 文件，并调整 vm.swappiness=10，让它尽量不用 Swap，除非万不得已。
禁用不必要服务：关闭防火墙中的非必要端口，停止 systemd 中不需要的服务（如 cups、bluetooth 等，如果是 Linux 发行版的话）。

如果你的目标是“低成本运营 WordPress”，1核1G 并不是最优解。考虑以下升级路径：

2核2G：这是 WordPress 的“甜点配置”。价格通常只比 1核1G 贵 30%-50%，但性能提升显著，可以流畅运行大多数插件，支持少量并发。
利用 CDN + 对象存储：将图片、CSS、JS 等资源全部托管到 OSS/COS 并通过 CDN 分发，减轻源站压力。
使用静态化博客：如果内容主要是文章，可以考虑迁移到 Hugo 或 Hexo 等静态生成器，部署到 GitHub Pages 或云存储桶，成本几乎为零，速度极快，完全无服务器运维压力。