正文

先选配置，再谈部署

我经手过最多的浪费，不是买贵，而是买错。有人用 2 核 2G 硬扛一个装了会员和电商插件的 WordPress，上线第三天数据库就卡到后台登不进去；也有人一上来买 8 核 16G，日均访问不到两千，多花的钱够再买两年同样的套餐。轻量应用服务器建站这件事，顺序永远是先想清楚站点类型和流量量级，再谈镜像和部署。配置定错了，后面所有调优都是在错误的地基上刷漆。

先把产品边界说清楚。轻量应用服务器和 CVM 云服务器不是一类东西。轻量卖的是套餐化：固定的 CPU、内存、系统盘和月流量包打成一档，公网带宽是峰值带宽，超出流量包按量补扣；CVM 卖的是可拼接：实例族（比如 S5、SA3、M6）、CBS 云硬盘、弹性公网 IP、CLB 负载均衡自由组合，能横向扩、能做跨可用区部署。轻量适合单机建站、个人博客、中小企业官网、轻量接口服务；一旦你要多机负载、独立数据库实例、跨可用区容灾，就该直接上 CVM，别指望用轻量硬撑。

还有两个数字必须分开看：带宽峰值和月流量包。腾讯云轻量常见的是小带宽配大流量，比如几 Mbps 峰值带宽配每月几百 GB 到 1TB 流量。带宽峰值决定瞬时的并发体验——几个人同时点开页面会不会转圈；流量包决定这个月你会不会额外掏钱。读多写少的静态内容站对这套组合很友好，但如果图片、视频不走对象存储，流量包往往月中就见了底，之后就是按量扣费甚至限速。

最后一个容易忽略的是系统盘。轻量的系统盘通常和套餐绑定，不能像 CVM 那样随手挂载多块 CBS。日志、缓存、备份文件如果都堆在系统盘，几个月就写满，机器直接卡死。我的习惯是，买之前就把数据盘或对象存储规划进去，别等磁盘告警了再补。

建站类型与推荐配置对照

下面这张表是我给客户做选型时的默认底稿，规格都是轻量常见档位，实际以控制台当前在售套餐为准。看表的顺序是：先用站点类型筛一遍，再用流量量级微调，不要拿着预算反过来凑配置。

建站场景 推荐规格（CPU/内存/系统盘） 带宽与流量建议 关键配置点

个人博客与静态站 2 核 2G，系统盘 50G SSD 3 至 5 Mbps 峰值，流量包 500G 以内 全静态化并前置 CDN，源站只处理更新请求

企业官网与展示站 2 核 4G，系统盘 60G SSD 5 Mbps 峰值，流量包 1T 开启 Nginx 静态缓存，媒体文件全部转对象存储

中型 WordPress 内容站 4 核 8G，系统盘 80G SSD 8 至 10 Mbps 峰值，流量包 1T 以上 PHP-FPM 进程数按内存反推，开 OPcache 与对象缓存

小型电商与会员站 4 核 8G 起，系统盘 100G SSD 带宽提到 10 Mbps，搜索与结算走内网 数据库单独规划，加 Redis 并对慢查询建索引

多站点与测试环境 2 核 4G，系统盘 60G，另挂数据盘 带宽共享，流量包按总量估算 面板多站点隔离，每个站点绑定独立 PHP 版本

有并发波动的活动页 4 核 8G，系统盘 100G SSD 带宽调高或前置 CDN 扛峰值 静态资源刷新到边缘，动态请求降级读缓存

这张表我强调一点：内存永远优先于 CPU。WordPress 这类以 PHP 加 MySQL 为主的站点，瓶颈九成出在内存不足导致的数据库缓存命中率低下，而不是 CPU 跑不动。同样预算下，宁可要 4 核 8G，也不要 8 核 4G。

应用镜像 vs 系统镜像：最容易选错的一步

轻量控制台里选镜像，第一眼看到的就是应用镜像：WordPress、宝塔面板、LNMP 环境、Docker、Node.js，甚至一键装好的建站套件。很多人图省事直接选应用镜像，装完发现能跑，就以为万事大吉，问题往往在两三个月后集中爆发。

应用镜像的本质是有人替你把环境装好了，代价是版本被锁死、路径被写死、升级链路受制于那个镜像的维护节奏。我见过太多站点，镜像里带的 PHP 版本比 WordPress 要求的还旧，插件因为版本不兼容报错；也见过镜像自带的 MySQL 参数按最低内存配置，站点一大就顶不住。更麻烦的是，脚本在安装时改过的配置文件，你后期照着官方文档去改反而改不对，排查半天才发现有个自定义的 include。

系统镜像则是干净的一张白纸：Ubuntu 22.04、Debian 12 或 Alibaba Cloud Linux 这类主流发行版，装完只有最小系统，环境全部自己搭。多花的那半小时其实是最值的半小时，因为每个版本、每个参数你都知道它从哪来。

我的建议很直接：如果是长期运营的正式站点，选系统镜像，然后自己装宝塔面板。只有在快速验证、临时演示、或者你完全不想碰命令行的场景下，才用应用镜像。

顺带说几个装完宝塔后必须立刻做的动作，这些坑很多同行不会主动告诉你。第一，宝塔面板默认端口是 8888，装完要去轻量控制台的防火墙里放行，同时 SSH 的 22 端口建议改端口并用密钥登录，关闭密码登录，每天扫 22 端口的爆破流量比你想象的多得多。第二，面板本身要绑定域名并开启面板 SSL，别用 IP 加端口裸奔。第三，phpMyAdmin 改成非默认端口或限制只允许你自己的 IP 访问，它能直接读写数据库，暴露在公网就是敞开大门。第四，数据库的 root 密码用强密码，并确认数据库只监听 127.0.0.1，不允许公网直连。

WordPress 部署全流程（含 Nginx、PHP、MySQL 的关键参数与版本选择）

版本选择上我给的默认组合是：Nginx 用稳定分支的最新版，PHP 用 8.1 或 8.2，数据库用 MySQL 8.0 或 MariaDB 10.6 以上，WordPress 保持最新大版本。WordPress 近几个大版本对 PHP 8 系列支持已经很成熟，继续抱着 PHP 7.4 跑，性能和安全性都吃亏。

PHP 扩展层面，opcache、fileinfo、exif、mysqli、imagick、redis 这几个是必装项，图片站尤其别漏 imagick，缩略图生成的效率差很多。

真正需要动手算的是 PHP-FPM 的进程数。规则很简单：每个 PHP-FPM 进程稳态大约占 30 到 50MB 内存，pm.max_children 要把内存总量减去系统、Nginx 和 MySQL 之后的余量除进去。2G 内存的机器，pm.max_children 设 8 到 12；4G 设 20 到 30；8G 可以给到 40 以上，但要同时把 MySQL 的 innodb_buffer_pool_size 留够。很多人把 max_children 设得极大，以为能扛更多并发，结果内存被打满触发 OOM，反而是把站点拖垮。pm 用 dynamic，start_servers 取 max_children 的五分之一到四分之一，min_spare_servers 略小于它，max_spare_servers 取三分之一左右，这套关系比具体数值更重要。

数据库这边，安装完先做三件事：字符集统一用 utf8mb4，避免后期表情符号和特殊字符乱码；在 wp-config.php 里确认数据库主机、字符集和 WP_CACHE 常量；innodb_buffer_pool_size 给到物理内存的 50% 到 70%，这是数据库性能最值钱的一个参数，比调任何其他开关都管用。

Nginx 侧的核心是开启 fastcgi_cache。建一个缓存目录，用 fastcgi_cache_path 定义 keys_zone、inactive 和目录层级，再用 fastcgi_cache_key 把请求方法、域名、URI 拼成缓存键，fastcgi_cache_valid 给 200、301、302 设一个三十分钟到一小时的缓存时长。关键是排除干扰：登录用户、带 cookie 的请求、后台路径和预览页绝不能吃缓存，否则会出现"后台改了文章前台看不到"的诡异故障。做法是定义一组跳过条件，命中时用 fastcgi_cache_bypass 和 no_cache 绕开。这一层配好，动态页面的响应会从走一遍 PHP 加数据库，变成 Nginx 直接吐缓存文件，效果立竿见影。

WordPress 后台别忘了两件事：固定链接改成 postname 形式，对 SEO 和缓存友好；关闭文章修订版本的无限堆积，否则 wp_posts 表会被撑得越来越大。

域名解析、HTTPS 与备案的先后顺序

这个顺序搞反，轻则白等几天，重则网站被拦截，所以单独拿出来讲。

第一步，域名注册并完成实名认证。域名实名的主体信息必须和后面备案的主体保持一致，这一步不一致，备案一定被退。

第二步，判断服务器所在区域。如果轻量服务器买在中国大陆，那么必须做 ICP 备案，没有例外。备案由接入商协助，主体需要是企业或符合要求的个人，且域名要和服务器在同一账号体系下能够证明接入关系。

第三步才是解析。备案通过之前，不要急着把主域名解析到国内服务器对外访问，因为未备案域名的访问会被拦截。这个阶段可以用本地改 hosts 的方式在开发机上调试，或者用临时域名做内部验证。

第四步，解析生效后申请证书。可以用云平台提供的免费 DV 证书，也可以用 Let's Encrypt，配好 443 端口并开启 HTTP 自动跳转 HTTPS。

这里要重点提醒 Let's Encrypt 的续期：它的证书有效期只有 90 天，宝塔面板申请证书时会自动建一个计划任务来续期，但这个任务经常出问题。常见原因有两个，一是验证用的 80 端口被防火墙封了，http-01 验证失败；二是服务器时间不准，导致签名校验异常。证书过期不会有人提前通知你，只会某天早上用户看到浏览器满屏红警告。所以部署完一定要手动触发一次续期测试，确认任务能跑通。

如果服务器在境外区域，就没有 ICP 备案这一步，面向中国大陆的访问速度和稳定性则要另行评估，这部分属于跨境部署的话题。

性能调优：从首屏 3 秒到 1 秒做了哪些事

我印象最深的一次，一个内容站首屏一直卡在三秒开外，客户的第一反应是服务器不够大，准备直接升配。我登上去看了一眼，首页渲染过程中查了两百多次数据库，每张配图都是没压缩的原图，插件装了三十多个。这不是钱的问题，是工程的问题。升配只能治标，而且很贵。

第一件也是最值的事：静态资源剥离到对象存储加 CDN。把图片、JS、CSS 上传到 COS，绑定 CDN 域名回源到 COS，WordPress 通过插件把媒体库地址指向对象存储。图片统一转成 WebP，首屏那一两张主图再单独做压缩。这一动作同时解决了三个问题：源站带宽占用下降、全国访问速度变均匀、磁盘不再被图片塞满。

第二件是 Nginx 静态缓存，前面讲过的 fastcgi_cache。装了缓存之后，绝大多数匿名访客的请求根本不会到 PHP 层，源站的算力只服务登录用户和后台。

第三件是 OPcache，而且它经常是被配置错的。核心参数就几个：opcache.enable 打开，opcache.memory_consumption 给 128MB 起步，opcache.max_accelerated_files 给到 10000 以上，opcache.validate_timestamps 在生产环境可以设成 0，代价是改代码后必须手动重载 PHP-FPM 才生效。很多面板装的 PHP 默认给 OPcache 只留了几十兆，连 WordPress 的脚本都缓存不全，等于没开。

第四件是对象缓存。用 Redis 把数据库查询结果缓存起来，WordPress 侧装 Redis Object Cache 插件，把 wp-config.php 里的缓存开关打开。Redis 只监听本机，不要暴露公网，也别把 Redis 和数据库设置成同一个弱密码。

第五件是数据库索引与慢查询治理。先开慢