【开发日记】2026年8月15日 — zs.lianluokeji.cn 网站性能优化：从6.6秒到0.25秒的25倍提升

🚀 今日开发概要

今天主要围绕 zs.lianluokeji.cn 网站做了一次深度的性能诊断和优化，从首页打开需要 6秒+ 优化到 0.25秒，整体提升了 25倍。同时还修复了 Zibll 主题的 PHP Warning 问题。

一、网站慢如蜗牛：诊断全过程

早上接到反馈说 zs.lianluokeji.cn 打开特别慢，用 curl 逐项测了一遍，结果触目惊心：

静态资源响应正常，说明 Nginx 没问题。慢的地方全在 PHP 动态请求上——典型的 WordPress 性能瓶颈。

二、三大根因定位

问题1：无页面缓存（最严重）

响应头显示 cache-control: no-store, no-cache, must-revalidate，意味着每次访问首页都要走完整的 PHP + MySQL 渲染流程。WordPress 的模板渲染涉及大量数据库查询和钩子函数，不缓存的话每次都是"从零开始"。

问题2：27个混合内容重定向

页面中有 27 个图片使用 http:// 加载，而网站已启用 HTTPS。每个 HTTP 请求都会被 Nginx 301 重定向到 HTTPS，意味着浏览器要发 双倍请求 才能加载一张图片。27 张图就是 54 次请求，光重定向就浪费了大量时间。

根因是 WordPress 的 siteurl 和 home 选项还停留在 http://，导致所有上传的图片 URL 都是 HTTP。

问题3：数据库查询极慢

WP REST API 耗时 14.5 秒，这个接口主要是查数据库。服务器只有 1.8GB 内存，MySQL 的 max_connections 却配了 500，每个连接都要预分配内存，导致 InnoDB Buffer Pool 严重不足，频繁换页。

三、五步修复方案

修复1：安装 WP Super Cache 页面缓存

通过 WP-CLI 安装并启用 WP Super Cache 插件，将首页从动态 PHP 渲染变为静态 HTML 输出。启用后首页 TTFB 从 6.6s 降到 0.25s。

修复2：数据库批量替换 HTTP → HTTPS

用 SQL 将 wp_options 表中的 siteurl 和 home 改为 HTTPS，再用 REPLACE 函数批量更新 wp_posts 表中的图片链接：

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://zs.lianluokeji.cn', 'https://zs.lianluokeji.cn');

27 个混合内容重定向全部消除。

修复3：安装 Redis 对象缓存

通过宝塔面板安装 Redis 6.2.22 + PHP Redis 扩展，再安装 Redis Object Cache 插件。数据库查询结果缓存到 Redis 内存中，WP REST API 从 14.5s 降到 0.14s——100倍的提升。

修复4：调整 PHP-FPM 配置

服务器仅 1.8GB 内存，但 PHP-FPM 的 max_children=30，每个 worker 约 70MB，总计 2.1GB 已超出物理内存。worker 被 OOM Killer 频繁杀掉，导致 502 错误。将 max_children 降为 10，内存使用回归正常。

修复5：重置宝塔面板密码

运维过程中发现宝塔面板密码遗忘了，通过 SSH 执行 bt 命令重置密码，恢复了面板访问权限。

四、优化效果对比

五、额外修复：Zibll 主题 PHP Warning

优化过程中发现页面顶部报了三个 PHP Warning：

Warning: Undefined variable $opacity05 in zib-head.php on line 123
Warning: Undefined variable $opacity3 in zib-head.php on line 124
Warning: Undefined variable $opacity6 in zib-head.php on line 125

原因是这三个变量只在 $color 有值时才被定义，但使用时没有提前初始化。PHP 8.2 对未定义变量的处理从 Notice 升级为 Warning。修复方式很简单：在变量使用前添加初始化 $opacity05 = ''; $opacity3 = ''; $opacity6 = '';。

今日感悟

WordPress 性能优化其实是个"组合拳"——页面缓存解决渲染慢，对象缓存解决查询慢，混合内容修复解决网络往返，PHP-FPM 调优解决内存溢出。每一项单独做效果有限，组合起来就是 25 倍的提升。最关键的一步是诊断：先用 curl 把 TTFB 测出来，区分静态资源慢还是动态请求慢，再对症下药。

另外，1.8GB 内存的低配服务器跑 WordPress 确实紧张，Redis + 合理的 PHP-FPM 配置是必须的。下次新部署 WordPress 站点，第一件事就是装缓存。