一、WordPress 到底吃多少资源
选配置之前，得先知道 WordPress 到底吃多少资源。 这一节先把这个数算出来，再谈买什么机器。
先说结论：WordPress 是个「不吃配置但很吃优化」的程序。 同样一台 1GB 机器，优化好的 WordPress 和装满插件的 WordPress，承载能力能差五倍。所以配置选型的逻辑不是「WordPress 很重所以要买大机器」，而是「先定你打算装多少东西，再倒推配置」。
先算默认状态的资源占用。 一个刚装好的 WordPress，空的、没有插件、只有默认主题：
| 项目 | 空站占用 | 说明 |
|---|---|---|
| PHP-FPM 进程池 | 约 40 到 60MB | 每个 worker 约 15 到 20MB |
| MySQL 或 MariaDB | 约 100 到 150MB | 含 InnoDB 缓冲池 |
| Nginx 与系统 | 约 60 到 80MB | 含 SSH 和基础服务 |
| 合计 | 约 200 到 290MB |
在 1GB 机器上，默认 WordPress 占用大约四分之一内存，看起来很宽裕。 但这只是起点。
然后算加上真实内容之后。 一个跑了半年、装了 10 个常用插件、发了 50 篇文章、积攒了 2000 条评论的中型博客：
| 项目 | 实际站点 | 增量来源 |
|---|---|---|
| PHP-FPM 进程池 | 约 150 到 250MB | 插件加载更多代码，worker 内存变大 |
| MySQL 或 MariaDB | 约 250 到 400MB | 缓冲池随数据量增长，索引也占内存 |
| Nginx 与系统 | 约 80 到 120MB | 访问日志和缓存文件 |
| 合计 | 约 480 到 770MB |
注意 PHP-FPM 那一栏。 从 50MB 涨到 200MB，涨了四倍，而且完全是插件带来的。 这就是为什么插件数量是 WordPress 运维里最重要的一个变量。
再算一次磁盘。 磁盘的消耗分三块：
- WordPress 核心加主题加插件： 约 50 到 100MB
- 数据库： 一个中型站点在 100 到 500MB，含文章、评论、修订记录和自动草稿
- 上传的图片： 这是唯一会无限增长的部分。 一年 300 张图、每张 200KB，就是 60MB；如果是图片站或者用了未压缩的大图，这个数字一年能到几个 GB
根据这些数，选型表出来了：
| 站点类型 | 内存 | 硬盘 | CPU | 说明 |
|---|---|---|---|---|
| 个人博客，10 个以内插件 | 1GB | 25GB | 1 核 | 装交换分区，慢一点但能用 |
| 内容型博客，20 个左右插件 | 2GB | 40GB | 2 核 | 最推荐的起步配置 |
| 外贸站加 WooCommerce | 2GB | 60GB | 2 核 | 数据库压力明显上升 |
| 电商站加多语言 | 4GB | 100GB | 2 核 | 插件数量决定上限 |
| 商城加高并发 | 4GB 及以上 | 150GB 以上 | 4 核 | 需要额外做对象存储和 CDN |
这张表和普通的建站配置表有个关键区别：它的下限由「插件数量」决定，上限由「并发」决定。 这两件事要分开算—— 很多人在这一步混淆了，结果买了 4GB 的机器却因为插件装太多还是慢。
关于 1GB 机器的实话：能用，但要接受三个限制。 第一，必须配交换分区；第二，插件数量要严格控制在 10 个以内；第三，不要装任何页面构建器类的可视化插件（比如 Elementor 这类），它们会让 PHP 内存占用翻倍。如果你的需求是「快速上线一个能用的博客」，1GB 加严格的插件纪律完全够；如果你要做的是精细排版的商业站，直接上 2GB 起步。
二、服务器配置和机房怎么定
上一节算的是「要多少」，这一节定「在哪买什么」。
先说欧洲机房对 WordPress 站点意味着什么。 欧洲VPS 的核心价值在于「离欧洲访客近」，而不是「离中国访客近」。 具体的量化标准是第九节的验收阈值：从欧洲访客的典型网络到你的站点，首字节时间要小于 300ms。 从德国或荷兰的机房出发，这个数字通常在 50 到 150ms 之间，有充足的余量。
但有一个必须说清楚的取舍：如果你做的是面向国内用户的 WordPress 站，欧洲机房是错误的选择。 从国内到欧洲的物理距离决定了首字节时间基本不可能低于 150ms，而且晚高峰时段国际出口拥塞会让这个数字翻倍。 这不是配置能解决的问题。做国内用户的站应该选香港、日本、新加坡这些节点；做欧洲或北美用户的站，才选欧洲机房。
配置的选择，重点看一个 WordPress 特有的指标：PHP worker 数量。
PHP-FPM 的 worker 数量决定了你的站点能同时处理多少个请求。 默认配置下这个数字往往等于 CPU 核心数，这在 WordPress 场景下是严重不足的——因为 WordPress 的每个请求都要跑 PHP，而 PHP 是典型的「I/O 等待多、CPU 占用少」的任务。 配置方法：
sudo nano /etc/php/8.2/fpm/pool.d/www.conf[www]
; 起始进程数，建议设为 CPU 核数的 2 倍
pm.start_servers = 4
; 最小空闲进程，保持常驻
pm.min_spare_servers = 4
; 最大空闲进程
pm.max_spare_servers = 8
; 最多同时处理多少请求
pm.max_children = 12
; 进程回收阈值
pm.max_requests = 500这几行的逻辑是： 4 个常驻 worker 保证常访客不用等进程启动，12 个上限决定并发峰值。 pm.max_requests = 500 那行尤其重要——它让每个 worker 处理 500 个请求后自动重启，作用是清理 PHP 进程里累积的内存泄漏。 WordPress 插件常年不更新的话，这个值能救命。
改完重启并确认生效：
sudo systemctl restart php8.2-fpm
# 确认 worker 数量已生效
sudo systemctl status php8.2-fpm磁盘类型对 WordPress 的影响，比大多数人想的要大。 WordPress 每次页面加载要查数据库、读模板、读插件文件，这三步全是随机小文件读取。 SATA SSD 和 NVMe 在这类负载上的差距是数量级的，表现就是「CPU 占用不高但页面就是慢」。 选机器时确认是 NVMe 而不是 SATA，这是一个直接对应用户体验的选项。
最后是流量。 WordPress 是典型的「流量消耗小于想象」的类型。 一个页面加上图片，按 1MB 算，按第二节前面那份访问量折算方法，一台带 5000GB 月流量的机器能撑约 1280 万次访问。 对绝大多数中小站，流量额度远远用不满，真正的问题是 CPU 和数据库。 所以选型时别为了流量额度去加钱，把钱花在内存和磁盘上更值。
三、PHP 版本和扩展怎么选
这一节是 WordPress 建站里最容易被忽略、但出问题最多的地方。
先说 PHP 版本的选择规则：
| PHP 版本 | WordPress 兼容性 | 建议 |
|---|---|---|
| 8.0 | 完全兼容 | 不建议，安全更新已停 |
| 8.1 | 完全兼容 | 可用 |
| 8.2 | 完全兼容 | 推荐默认版本 |
| 8.3 | 完全兼容 | 新站可用，注意插件兼容性 |
| 7.4 | 完全兼容 | 已停止安全更新，不建议 |
核心原则是「跟随发行版默认版本，不要自己升到最新」。 Debian 12 自带 PHP 8.2，Ubuntu 24.04 自带 PHP 8.3——用发行版自带的版本，能省掉大量编译和依赖问题。 自己加第三方源装 PHP 8.4 之类的版本，遇到插件不兼容时你会花很久去定位到底是插件的问题还是 PHP 的问题。
安装 PHP 及 WordPress 需要的扩展：
sudo apt install -y php-fpm php-mysql php-mbstring php-xml php-curl php-zip php-gd php-intl php-bcmath每个扩展对应一个具体需求，记住用途就不会漏装：
| 扩展 | 用途 | 不装会怎样 |
|---|---|---|
| php-mysql | 连接数据库 | 装不了 WordPress |
| php-mbstring | 多字节字符串处理 | 中文标题乱码，截断异常 |
| php-xml | XML 解析 | 部分插件无法使用 |
| php-curl | 远程请求 | 无法调用外部 API，WordPress 更新失败 |
| php-zip | 解压 | 无法自动更新主题和插件 |
| php-gd | 图像处理 | 无法生成缩略图，上传后尺寸不对 |
| php-intl | 国际化 | 多语言插件报错 |
| php-bcmath | 高精度运算 | 某些支付插件计算失败 |
php-mbstring 和 php-gd 是最常被漏掉的两个。 mbstring 漏了，中文站点的标题长度计算会出错，表现为「标题被莫名截断成 20 个字符」；gd 漏了，WordPress 无法生成图片缩略图，媒体库里会堆满原始大图，磁盘很快涨起来。
装完之后确认扩展都加载上了：
# 列出已加载的 PHP 扩展
php -m | sort
# 或者用命令直接查单个扩展
php -r "echo extension_loaded('mbstring') ? 'mbstring loaded' : 'MISSING';"关于 OPcache，这是 WordPress 站点上收益最大的单个优化。 它的作用是把 PHP 脚本编译结果缓存在内存里，第二次以后的请求就不用重新解析和编译。 对 WordPress 这种「代码量大、执行时间短」的典型负载，效果通常很明显：
sudo apt install -y php-opcache
sudo nano /etc/php/8.2/fpm/conf.d/99-opcache.iniopcache.enable = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
; 每次请求都检查文件修改时间，发布代码后能立即生效
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60opcache.validate_timestamps = 1 这一条在开发环境要开着，在生产环境可以关掉。 关掉之后 PHP 不再检查文件修改时间，性能还能再提一点，但你在服务器上改代码后必须手动重启 PHP-FPM 才能生效——忘了这一步，你会以为自己的修改没生效，排查半天。
另一个必做的是限制 PHP 的资源占用，防止单个坏插件拖垮整台机器：
; 单个脚本最多用多少内存
memory_limit = 256M
; 脚本最长执行时间
max_execution_time = 300
; 上传文件大小限制
upload_max_filesize = 64M
post_max_size = 64Mmemory_limit = 256M 是 WordPress 的合理起点。 设成 128M 的话，任何需要处理大图的插件都会直接报致命错误；设成 512M 以上则意味着一个脚本就能吃掉大半台机器的内存，在 2GB 机器上风险太大。
四、安装前必须先做的四件事
这一节讲的是装 WordPress 之前要准备好的东西。 **跳过任何一步，装的时候都会出问题。
第一件：确认服务器上没有残留的旧站点。 很多机器是重装过的或者从别人手里转过来的，里面可能有旧的数据库和旧的文件。 装之前清干净：
# 看站点目录里有什么
ls -la /var/www/html/
# 清空并重建
sudo rm -rf /var/www/html/*
sudo mkdir -p /var/www/html/your-site/public
sudo chown -R www-data:www-data /var/www/html/your-site第二件：把 WordPress 核心文件下载到正确的位置。 注意是「正确的位置」——这个位置在第四节的 Nginx 配置里已经定好了，是 public 子目录。
cd /tmp
# 下载最新版本
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
# 只复制核心文件（不含 wp-content），核心文件保持干净，以后升级时不容易出问题
cp -r wordpress/* /var/www/html/your-site/public/
cp -r wordpress/wp-content /var/www/html/your-site/
# 设置归属权
sudo chown -R www-data:www-data /var/www/html/your-site为什么只复制核心文件而不整包复制？因为 wp-content 目录里放的是你的主题、插件和上传文件，这些必须留在外面。 WordPress 官方推荐的做法就是核心文件每次升级都重新下载，wp-content 只在升级时保留，这样升级出问题可以直接换回上一版核心文件。
第三件：建好数据库和独立用户。 这一步在通用建站教程里讲过，WordPress 场景补充一点：数据库名和用户名尽量短且纯字母，因为它们要写进 wp-config.php，带特殊字符会引入转义问题。
sudo mysql -u rootCREATE DATABASE wordpress_wp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY '你的强密码';
GRANT ALL PRIVILEGES ON wordpress_wp.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;第四件：写好 wp-config.php。 WordPress 装完会自动生成这个文件，但手动写好再装，能避免中途因为配置问题卡住：
cd /var/www/html/your-site/public
sudo cp wp-config-sample.php wp-config.php# 用脚本写入数据库信息和随机盐
sudo tee -a wp-config.php > /dev/null << 'PHPEOF'
define( 'DB_NAME', 'wordpress_wp' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', '你的强密码' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );
PHPEOF# 生成 8 个随机盐（每次执行结果不同，保留本次输出）
curl -s https://api.wordpress.org/secret-key/1.1/salt/把上面输出的 8 行 define 追加到 wp-config.php 里。 盐值的作用是让登录 Cookie 在不同站点之间无法复用，防止 Cookie 被盗后在另一个站点复用。
这四件事做完，再打开浏览器访问你的域名，WordPress 的安装向导才会出现。 如果向导没出现或者报数据库错误，回到上面四步逐项检查，不要往下走。
五、插件和主题怎么控制
这一节是 WordPress 长期维护的核心。
先给一条硬性数字：一个 WordPress 站点的插件数量控制在 15 个以内。 这不是拍脑袋，理由有三个：每个插件都会加载自己的 PHP 代码进入内存；每个插件都注册自己的定时任务和 AJAX 钩子；每个插件都是一个新的安全面。
插件按功能分类，15 个名额怎么分配：
| 类别 | 建议数量 | 说明 |
|---|---|---|
| 缓存类 | 1 个 | 只装一个，多个缓存插件会互相冲突 |
| 安全类 | 1 到 2 个 | 功能重复的不要同时装 |
| SEO 类 | 1 个 | 装两个会输出重复的 meta 标签 |
| 表单与邮件类 | 1 到 2 个 | 决定邮件能不能发出去 |
| 备份类 | 1 个 | 备份插件也是插件，同样吃资源 |
| 页面构建器 | 0 到 1 个 | 最吃内存的一类，能不用就不用 |
| 其余功能类 | 按需 | 每加一个前先想清楚必要性 |
「缓存插件只装一个」这条要重点说。 常见的冲突组合是 WP Super Cache 加 W3 Total Cache 加 WP Rocket，结果不是缓存更快，而是页面出现空白或者样式全乱，因为三个插件都在改 wp-config.php 里的缓存配置常量。如果不确定装哪个，选默认推荐的那个就好。
主题的选择，原则是「越简单越好」。 一个用 Elementor 或 Beaver Builder 这类可视化构建器做的主题，页面编辑器会实时调用 PHP 生成预览，这会让后台打开时的内存占用是前台的 3 到 5 倍。 在 1GB 机器上，用可视化构建器打开页面编辑器会直接触发 OOM。
如果你确实要用可视化构建器，配置要求就要提高： 2GB 起步，最好 4GB。
还有一个常被忽略的清理动作：停用不用的插件，而不是删除。
# 在数据库里看各插件占用的内存（需要 WP_DEBUG_LOG 开启）
# 或者用 wp-cli 直接看
wp plugin list --fields=name,status,update「停用而不是删除」的原因很简单：插件停用后不加载代码，但文件还在，出问题时可以随时启用回来；删除之后如果发现还需要，得重新找、重新装、重新配置。
主题同理，建议保留一个「兜底主题」：在服务器上放一个最基础的主题，当主主题出问题时（常见于主题更新后与插件不兼容），可以在后台一键切换到兜底主题，站点立刻恢复可访问。 这是很多建站教程没提但实战里救命的一招。
最后是更新策略。 核心、主题、插件的更新节奏不一样： WordPress 核心在每个版本发布后的第一次安全更新就可以升，不要等到大版本跨级升级；主题和插件则要先在测试环境验证再上生产，因为它们是第三方代码，你不知道这次更新改了什么。至少保留一个子目录做测试站，升级前先在测试站跑一遍。
六、缓存和数据库怎么优化
这一节讲的是让 WordPress 跑得快的两个核心优化。
先说缓存。 缓存的作用是把「每个访客都要跑一遍的 PHP 计算」变成「一次计算、多次复用」。 WordPress 页面生成的典型路径是：查数据库取文章、执行插件的 PHP 代码、渲染模板、拼装 HTML。对访客来说，其中 90% 的访客看的是同一篇文章，所以这部分结果应该被缓存。
缓存分三层：
| 层级 | 缓存什么 | 效果 | 实现方式 |
|---|---|---|---|
| 页面缓存 | 完整的 HTML 输出 | 访客直接拿到 HTML，PHP 完全不执行 | 缓存插件或 Nginx 层 |
| 对象缓存 | 数据库查询结果 | 减少数据库查询次数 | Redis 或 Memcached |
| 浏览器缓存 | 静态资源 | 访客二次打开不重新下载 | 响应头加 Cache-Control |
对大多数 WordPress 站点，第一层就够用了。 装一个页面缓存插件，把「缓存有效期」设成比较长的值（比如几小时到一天），在文章发布或更新时自动清空缓存。
第二层对象缓存，只有在数据库查询成为瓶颈时才需要。 判断方法：
# 开启慢查询日志后，观察一段时间
sudo tail -50 /var/log/mysql/mysql-slow.log
# 看数据库当前的连接数和状态
mysql -u root -e "SHOW STATUS LIKE 'Threads_connected'; SHOW STATUS LIKE 'Questions';"看到大量重复的查询、或者 Queries 数持续快速增长，就该上对象缓存了。 WordPress 本身支持通过 wp-content/object-cache.php 接入 Redis，但这需要服务器上装 Redis 并做持久化配置，对 1GB 机器来说是个不小的负担。
第三层浏览器缓存在第五节的 Nginx 配置里已经写过了（静态资源 30 天缓存加 immutable 标记）。
然后是数据库优化。 对 WordPress 来说，数据库的负担主要来自三处：**
第一处是文章修订记录。 WordPress 默认每隔几分钟就存一次修订记录，一个经常编辑的博客半年能积累几千条修订记录。 每一行修订都是一次数据库写入，而且后台的「修订」列表查询会明显变慢。 清理办法：
# 用 wp-cli 删除所有修订记录（保留自动草稿）
wp post delete $(wp post list --post_type=revision --format=ids) --force第二处是过期评论和垃圾评论。 Akismet 插件能挡住大部分垃圾评论，但挡不住的会堆积。定期清理能显著减小数据库体积。
第三处是自动草稿。 WordPress 会自动保存草稿，很多人在浏览器里开了很多标签页，就留下了大量自动草稿。
这一条最值得做：给 wp-config.php 加一个限制，把修订记录的数量压下来。
// 限制保存的修订版本数量，5 是够用的
define( 'WP_POST_REVISIONS', 5 );
// 把自动草稿的保存间隔从 60 秒延长到 300 秒
define( 'AUTOSAVE_INTERVAL', 300 );还有一个数据库层面的优化是调整 InnoDB 缓冲池。 这个值默认往往偏小，在 2GB 内存的机器上，设为 256M 到 512M 是合理的：
[mysqld]
innodb_buffer_pool_size = 256M
innodb_log_file_size = 64M
innodb_flush_log_at_trx_commit = 2innodb_flush_log_at_trx_commit = 2 这一行要说明一下：它把每次事务提交的刷盘改成每秒一次， 换来的是写入性能提升，代价是极端情况下（机器突然断电）可能丢失最后一秒的事务。 对普通博客这个取舍是划算的，但如果你的站是订单系统，这一条不要改。
最后是对象缓存的替代方案：如果你的访客集中在欧洲，Nginx 层的缓存比 PHP 层的缓存更快。 因为它省掉了 PHP 启动和数据库查询的开销。用 Nginx 的 fastcgi_cache 就能实现，配合上节的 try_files 指令，具体参数需要根据你的实际路径规则调整，建议先在测试环境验证再上生产。
七、WordPress 常见报错和排查
这一节按「报错现象」组织，每种现象给出定位方法和处理办法。
现象一：安装向导报「数据库连接错误」。 按这个顺序查，每步一条命令：
# 1. 数据库服务在跑吗
sudo systemctl status mariadb
# 2. 用 wp-config.php 里的账号手工连一次
mysql -u wp_user -p'你的密码' wordpress_wp -e "SELECT 1;"
# 3. 密码里的特殊字符是不是在 wp-config.php 里被转义了
grep -n "DB_PASSWORD" /var/www/html/your-site/public/wp-config.php第 2 步能连上但 WordPress 连不上，通常是 DB_HOST 写错了。 localhost 和 127.0.0.1 在 MySQL 里不是一回事：localhost 走 Unix socket，127.0.0.1 走 TCP。 如果数据库在远程或者用容器，localhost 就是错的。
现象二：后台打开是白屏，前台正常。 这是 WordPress 最经典的问题，99% 是插件或主题的 PHP 致命错误。 打开调试日志看具体原因：
# 打开调试（WP_DEBUG_DISPLAY 保持 false，日志写文件）
sudo nano /var/www/html/your-site/public/wp-config.phpdefine( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );# 看错误日志
sudo tail -30 /var/www/html/your-site/public/wp-content/debug.log应急处理：把出问题的插件改名禁用。 这是最快的方法，因为 WordPress 检测插件是靠目录名：
# 列出所有插件目录
ls /var/www/html/your-site/wp-content/plugins/
# 把可疑插件改名（改名即禁用）
sudo mv /var/www/html/your-site/wp-content/plugins/问题插件目录 /var/www/html/your-site/wp-content/plugins/问题插件目录.disabled现象三：后台提示「您的 PHP 内存分配不足」。 这个提示本身就是解决方向。 按第三节的办法调 memory_limit，同时把 pm.max_children 调小一点——这两个值要一起调整，否则 PHP-FPM 会因为 worker 太多而耗尽物理内存。 常见错误是只把 memory_limit 提到 512M 而不管 worker 数量，结果 12 个 worker 各占 512M，2GB 机器直接 OOM。
现象四：网站变慢，后台也变慢。 大概率是数据库问题而不是 PHP 问题。 先看是不是有慢查询：
# 看慢查询日志
sudo tail -50 /var/log/mysql/mysql-slow.log
# 看数据库连接数
mysql -u root -e "SHOW PROCESSLIST;"
# 看磁盘 IO 状态（有 iostat 的话）
sudo iostat -x 1 3如果看到大量 Copying to tmp table 类型的慢查询，那多半是某个插件的查询没有走索引，这类问题需要靠优化插件或者加索引解决。
现象五：上传图片失败，报「上传大小超过限制」。 三处限制要同时调，之前提过，这里再列一次：
# 1. Nginx
sudo nano /etc/nginx/sites-available/your-site
# client_max_body_size 64M;
# 2. PHP 的 upload_max_filesize 和 post_max_size
sudo nano /etc/php/8.2/fpm/conf.d/99-site.ini
# 3. WordPress 自己的设置（后台 → 媒体 → 上传）改完必须重启 PHP-FPM 和 reload Nginx，只改配置文件不重启是不生效的。
现象六：更新插件时页面卡住，最后 502 或 504。 这是超时。 处理办法是第三节提到的 fastcgi_read_timeout 300，同时把 max_execution_time 也调大。如果还是不行，那就是服务器资源真的不够—— 插件更新要在解压和写文件，吃磁盘 IO，1GB 内存配 20GB 硬盘的机器做这件事会很吃力。
现象七：邮件发不出去。 这是独立主机最常见的问题之一。 WordPress 默认用 PHP 的 mail() 函数发信，而大多数主机会禁掉这个函数。 解决办法是装 SMTP 插件（WP Mail SMTP 之类）并配置第三方邮件服务的 SMTP 凭据。配置时注意 465 端口用 SSL、587 端口用 TLS，这两种配错都会失败。
八、上线后怎么判断这个站是否健康
这一节给一套可量化的健康检查。 站点上线不是终点，是监控的开始。
先说最关键的一条：WordPress 站点的健康状况，八成可以从后台打开速度上看出来。 如果你在后台操作时感觉明显发木，那前台访客的体验一定也是差的。
要盯的六组数字：
| 检查项 | 怎么看 | 合格标准 | 不合格指向 | |
|---|---|---|---|---|
| 后台页面加载时间 | 浏览器开发者工具的网络面板 | 低于 1.5 秒 | 插件过多或数据库慢 | |
| 内存占用 | free -m 看 used 列 |
谷值低于 15% | 插件常驻或存在泄漏 | |
| 数据库大小 | SELECT SUM(data_length+index_length) FROM information_schema.tables |
低于 500MB | 修订记录或垃圾数据堆积 | |
| 磁盘使用率 | df -h / |
低于 70% | 上传图片或日志未清理 | |
| PHP 错误日志 | tail /var/.../debug.log |
无新增错误 | 插件有兼容性问题 | |
| SSL 证书剩余天数 | `echo | openssl s_client` 检查 | 大于 30 天 | 续期流程可能失败 |
内存那条要重点讲。 WordPress 站点的内存占用是单向增长的——插件装上去了不会自己卸载，文章写多了对象缓存里的条目也更多。唯一的判断方式就是长期记录谷值，而不是看某一刻的数值。 记录方法：
# 每小时记录一次内存和数据库大小
0 * * * * echo "$(date '+%F %T') mem=$(free -m | awk '/Mem:/{print $3}')M db=$(mysql -u root -N -e 'SELECT ROUND(SUM(data_length+index_length)/1048576) FROM information_schema.tables')MB" >> /var/log/wp-health.log跑一个月，你就有了一条曲线。 这条曲线能回答一个关键问题：「如果下个月要迁服务器，现在的配置够不够？」
第二个长期任务是检查 WordPress 核心、主题和插件的更新。 这三者的更新节奏不一样：
| 组件 | 更新建议 | 理由 |
|---|---|---|
| WordPress 核心 | 每个版本发布后第一次安全更新就升 | 不跨大版本升级，出问题好回滚 |
| 主题 | 每月一次，先在测试站验证 | 主题更新可能改模板标记 |
| 插件 | 每月一次，先在测试站验证 | 第三方代码，质量不可控 |
验证的方式是在服务器上建一个测试子目录：
# 用子目录做一个测试站
sudo mkdir -p /var/www/html/test.your-domain.com/public
sudo cp -r /var/www/html/your-site/wp-content /var/www/html/test.your-domain.com/在测试站上先跑一遍更新，确认没问题再在生产站做。 这一步能挡掉绝大多数「更新完网站白了」的事故。
第三个长期任务是清理。 建议每月做一次：
# 删修订记录和自动草稿
wp post delete $(wp post list --post_type=revision --format=ids) --force
wp post delete $(wp post list --post_type=auto-draft --format=ids) --force
# 删过期评论
wp comment delete $(wp comment list --status=spam --format=ids) --force
# 删未使用的附件（先 --dry-run 看看会删什么）
wp post list --post_type=attachment --format=ids | xargs -r -n1 wp post delete --force注意最后一条要谨慎。 删除未使用的附件前，一定要先在测试站跑 wp post list --post_type=attachment --format=ids 人工核对，因为「未使用」只是说它没被任何文章引用，但有可能它是你手动上传准备用的素材。
最后一个长期任务：证书和域名的续期。 证书过期是 WordPress 站点最典型的「无声故障」——流量曲线完全正常，只是某天开始全站 HTTPS 报错。 单独配一个提醒，比靠记性好。
关于这个提醒怎么做，有个具体建议：不要只依赖 Certbot 的自动续期，要有一条独立的外围校验。 自动续期本身是可以工作的，但它失败的时候是静默的——Certbot 只在自己的日志里记一笔，你的站点不会有任何提示。 所以配一条独立检查更稳妥：
# 每天检查一次证书剩余天数，不足 30 天就记一条告警
CERT_DAYS=$(echo | openssl s_client -servername your-domain.com 2>/dev/null \
| openssl x509 -noout -enddate \
| sed 's/notAfter=//')
DAYS_LEFT=$(( ( $(date -d "$CERT_DAYS" +%s) - $(date +%s) ) / 86400 ))
if [ "$DAYS_LEFT" -lt 30 ]; then
echo "$(date '+%F %T') WARN cert expires in $DAYS_LEFT days" >> /var/log/cert-alert.log
fi这条脚本和自动续期是互补关系：自动续期负责续，这条负责告诉你自动续期是不是真的在工作。 两者缺一不可。
还有一件值得做的事：把上面这些检查项汇总成一份「健康报告」，每周发给自己一次。 核心指标就五个： 内存谷值、磁盘使用率、数据库大小、PHP 错误日志新增行数、证书剩余天数。每周花三分钟看一眼，比出问题后花三个小时排查划算得多。
九、上线验收清单和具体推荐
这一节给你一张可以直接签字的验收表，以及按不同情况给出的具体推荐。
上线前必须全部通过的八项验收：
| 验收项 | 测试方法 | 合格标准 |
|---|---|---|
| 首页可访问 | 外部网络访问域名 | 返回 200 且渲染完整 |
| HTTPS 有效 | 浏览器访问 | 无证书警告，锁形图标正常 |
| HTTP 自动跳转 | 访问 http 域名 | 301 跳转到 https |
| 后台可登录 | 后台登录并打开文章列表 | 无报错，加载在 1.5 秒内 |
| 数据库连接 | 后台打开「站点健康」页面 | 显示数据库连接正常 |
| 首字节时间 | 连续请求 20 次取中位数 | 小于 300ms |
| 1MB 下载耗时 | 连续下载 20 次取中位数 | 小于 2s |
| 内存谷值 | 连续 24 小时记录 | 不高于 15% |
| 备份可用 | 手动跑一次备份并解包 | 文件完整能解包 |
关于「首字节小于 300ms」这条在欧洲机房语境下的补充： 从欧洲访客的典型网络出发，这个数字通常在 50 到 150ms 之间，余量很足。但如果你的访客主要在国内，欧洲机房再快也做不到 300ms 以内—— 这是物理距离决定的，这时候该考虑的是换机房，不是换配置。
现在给具体推荐。
如果你只是要一个自己的博客，内容不多、访问量小：选 1GB 内存 25GB 硬盘 1 核的机器。 但要接受三个条件：插件控制在 10 个以内、不装可视化构建器、装交换分区。 配置上用 Debian 12 加 PHP 8.2 加 MariaDB，这套组合的稳定性是经过大量验证的。 价格请以官网当日报价为准。
如果你做的是内容型站点或者小型外贸站：选 2GB 内存 40GB 硬盘 2 核，这是最推荐的起步配置。 这个配置能装 20 个插件、跑 Elementor、扛住每天几千次访问，而且在预算上比 4GB 省一半。更重要的是它给了你内存谷值的安全余量—— 2GB 机器跑一个优化好的 WordPress，谷值通常在 20% 到 30% 之间，余量比 1GB 机器宽裕得多。
如果你做电商（WooCommerce）：直接上 4GB 内存。 不要省。 WooCommerce 的订单数据、购物车 session、以及各种支付插件的回调，对数据库的写压力比博客高一个数量级。 2GB 能跑起来，但高峰期数据库连接数容易打满，表现为下单时卡住。 同时一定要把商品图片放到对象存储，不要放在本地盘——电商站的图片会持续增长，这是唯一会无限消耗磁盘的部分。
如果你需要多语言、多站点或者内容量大：4GB 内存 100GB 硬盘起步，并且把静态资源分离出去。 静态资源分离的做法是把图片和附件目录指向对象存储，配合 CDN。 这样做的收益有两层：服务器磁盘不再无限增长，访客的加载速度也不再受服务器带宽限制。
最后一条不分情况都适用的建议：先按月付一个月，把第八节的六组数字测出来。 一个月之后你手里就有真实数据，而不是「我觉得应该够」的判断。 这时候再决定要不要升配、要不要转年付、要不要迁机房—— 这些决定都应该由数据驱动，而不是由预算余量驱动。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 itldc 当前机型与价格
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 iwebfusion 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 spinservers 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
