网站响应慢的四大根源及对策：一是Nginx静态资源缓存未开启，需配置expires与Cache-Control；二是PHP-FPM进程不足或超时，应调优max_execution_time和pm.max_children；三是WordPress数据库冗余（如transient数据、插件残留表），须清理并优化索引；四是CDN与本地缓存策略冲突，需分层设置缓存时效、添加版本号、验证命中率。
网站响应慢，先看 Nginx 缓存是否生效
宝塔面板默认不开启静态资源缓存，nginx.conf 里没有 expires 或 add_header Cache-Control 配置，浏览器每次都要重新拉取 JS、CSS、图片，首屏加载自然拖沓。
实操建议：
- 进宝塔 → 网站 → 对应站点 → 设置 → 配置文件，在
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$块内补上：expires 30d; add_header Cache-Control "public, immutable";
- 避免对
.php或带?查询参数的 URL 加缓存，否则可能缓存动态内容导致数据错乱 - 改完点“保存”，再点“重载配置”，别只点保存就以为生效了
- 用浏览器开发者工具的 Network 标签页，刷新后看响应头里有没有
Cache-Control和Expires，没有就是没生效
PHP-FPM 进程卡死或超时，检查 max_execution_time 和 pm.max_children
访问变慢常伴随 502 错误或页面卡在“正在加载”，大概率是 PHP-FPM 子进程不够用，或者单个请求跑太久被强制终止。
实操建议：
- 进宝塔 → 软件商店 → 找到当前 PHP 版本 → 设置 → 配置修改，确认
max_execution_time不低于 30（WordPress 插件更新等场景容易超时） - 在
www.conf中调整pm.max_children：如果服务器有 2G 内存，设为20是较安全的起点；设太高会导致 OOM 被系统 kill - 观察宝塔面板首页的“PHP-FPM”实时状态，若“活跃进程数”长期接近
pm.max_children，说明真缺资源，不是调参能解决的 - 别盲目开
pm = ondemand——低配机器反而更容易因频繁启停子进程而抖动
数据库查询慢，优先查 WordPress 的 wp_options 表和未清理的插件残留
很多“慢网站”其实和代码无关，而是数据库里堆了上万条 transient 记录，或者某插件卸载后没删表，每次 wp_query 都要扫一遍垃圾数据。
实操建议：
- 用宝塔 → 数据库 → phpMyAdmin，执行：
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%';
- 检查是否有明显异常的大表，比如
wp_simple_history_logs或wp_wpforms_tasks_meta，这些是插件日志表，通常可清空 - 给
wp_options表的autoload字段加索引（仅当该字段值大量为yes且查询变慢时才需要）：ALTER TABLE wp_options ADD INDEX idx_autoload (autoload);
- 禁用“WP Super Cache”之类缓存插件后再测速——有时插件自身逻辑比不缓存还慢
CDN 和本地缓存混用时，Cache-Control 冲突导致资源不更新
开了 CDN 又在 Nginx 里设了 Cache-Control: public, max-age=31536000，结果改完 CSS 用户刷半天还是旧样式，因为 CDN 把一年期缓存钉死了。
实操建议：
- 静态资源路径末尾加版本号或哈希，比如把
style.css改成style.css?v=2.3.1，这样 CDN 缓存的是新 URL，旧缓存自动失效 - CDN 后台把 HTML 页面缓存时间设为
0或60s，JS/CSS/图片单独设长缓存，别一刀切全设一年 - 检查响应头中
X-Cache（阿里云）或X-Cache-Hits（腾讯云）是否为HIT，如果是MISS居多，说明缓存根本没打中，得回头查规则匹配逻辑 - 本地 Nginx 的
expires建议设为7d而非30d，留出缓冲余地，避免 CDN 和源站缓存策略打架
真正卡顿的根源往往不在“要不要开缓存”，而在于哪一层缓存该管什么、谁先谁后、失效怎么联动。调过三遍以上还没起色，大概率是某个插件在后台偷偷发起同步请求，或者数据库连接池早被占满——这时候看日志比调配置更管用。
