本文约 3,337 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：同一个站点，换了个缓存插件速度差了两倍
有个很典型的对比：两台配置一样的服务器，同样的 WordPress 站点，一台装 WP Rocket，另一台装 LiteSpeed Cache。前者的首页 TTFB 是 180ms，后者是 45ms。差距不在插件谁写得更好，而在于后者根本没经过 PHP。
LiteSpeed Web Server（LSWS）和 OpenLiteSpeed（OLS）自带服务器级缓存：请求进来后由 Web 服务器直接判断缓存命中，命中就直接返回静态文件，PHP-FPM 完全不参与。而 WP Rocket 跑在 Apache 或 Nginx 上时，虽然也生成静态 HTML 文件并通过 .htaccess/Nginx 规则直接返回，但要走一遍 rewrite 判断和文件查找，在 Nginx 上还需要额外配置规则才能做到”不启动 PHP”。
所以这个问题的答案其实很直接：你的 Web 服务器决定了你的首选插件，预算和运维习惯只是次要因素。
原理分析：两层缓存的本质差别
| 维度 | WP Rocket | LiteSpeed Cache |
|---|---|---|
| 缓存层级 | 应用层（生成静态 HTML + 服务器 rewrite 规则） | 服务器层（LSWS 内置缓存引擎） |
| 适用服务器 | Apache 原生支持；Nginx 需手工加规则 | 仅 LiteSpeed / OpenLiteSpeed（LSWS/OLS） |
| 免费与否 | 付费（年订阅） | 免费（CDN 与图片优化需 QUIC.cloud 配额） |
| 缓存命中标识 | x-rocket-nginx-serving-static 等 |
x-litespeed-cache: hit |
| 附加能力 | CDN、数据库清理、延迟 JS、关键 CSS | 爬行器、图片优化、对象缓存（Redis）、ESI、QUIC.cloud CDN |
| 配置复杂度 | 低，开关为主 | 中高，选项密集 |
关键的判断依据是：能不能让请求不启动 PHP。可以用一个命令自测：
# 看服务器是什么
curl -sI https://mimangfei.com/ | grep -Ei '^(server|x-litespeed|x-powered-by|x-rocket)'
# 若返回 server: LiteSpeed，说明可以走服务器级缓存
如果 server: 返回的是 LiteSpeed，那 LiteSpeed Cache 的收益是架构级别的；如果是 Nginx 或 Apache，LiteSpeed Cache 插件就退化成一个普通的应用层缓存插件，完全没必要用它，直接上 WP Rocket（或免费方案）更合适。
第二个判断维度是运维投入。LiteSpeed Cache 的能力上限更高（ESI 可以做”整页缓存 + 局部动态”，WooCommerce 购物车能保持整页缓存），但配置项密集，默认配置在某些情况下会缓存不该缓存的内容；WP Rocket 默认配置就比较安全，代价是精细控制能力弱。
第三个维度是成本与依赖。LiteSpeed Cache 免费，但其图片优化、Critical CSS 生成、CDN 都依赖 QUIC.cloud 服务，免费额度用完后要么付费要么自己关掉；WP Rocket 是纯本地插件，付费买断的是功能本身，不依赖外部服务。
保姆级实操：三步确定选型
第一步：确认 Web 服务器类型
# Nginx / Apache / LiteSpeed 一眼看清
curl -sI https://mimangfei.com/ | grep -i '^server:'
# 或用 WordPress 侧的服务器软件信息
wp eval "echo \$_SERVER['SERVER_SOFTWARE'] ?? 'unknown';" 2>/dev/null
第二步：量基线，再装插件对比
# 装插件前先记 5 次 TTFB
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "TTFB=%{time_starttransfer}s 总=%{time_total}s\n" https://mimangfei.com/
done
装完插件、清缓存、预热之后，再跑一次同样的命令对比。注意第一次请求必然是未命中，要取第二次之后的数值。
第三步：按环境落决策
- LiteSpeed / OpenLiteSpeed：装 LiteSpeed Cache，优先配置 Cache → Enable Cache，再配置 Crawler 与图片优化；
- Nginx：WP Rocket（付费）或免费方案；装 WP Rocket 后要确认 Nginx 里包含了插件生成的缓存规则；
- Apache：WP Rocket 开箱即用，
.htaccess会自动写入。
Nginx 上配合 WP Rocket 时，需要确认配置文件里包含了类似这样的规则：
# Rocket-Nginx 风格：命中静态缓存则不走 PHP
set $rocket_cache 1;
if ($request_method = POST) { set $rocket_cache 0; }
if ($query_string != "") { set $rocket_cache 0; }
location / {
try_files "/wp-content/cache/wp-rocket/$http_host/$uri/_index.html" $uri $uri/ /index.php?$args;
}
第四步：确认命中状态
# LiteSpeed
curl -sI https://mimangfei.com/ | grep -i 'x-litespeed-cache'
# WP Rocket
curl -sI https://mimangfei.com/ | grep -iE 'x-rocket|cache-control'
常见踩坑
- 在 Nginx 上装 LiteSpeed Cache。插件能跑，但核心的服务器级缓存用不上，白白多一堆配置。
- 两个缓存插件同时开。会互相拦截、缓存规则冲突，前台出现诡异的旧内容。
- 案例：一个外贸站从 Apache 迁到 OpenLiteSpeed，站长沿用原来的 WP Rocket 配置，忘记在 OLS 里加 rewrite 规则，结果静态 HTML 生成了但没人读，每个请求还是走 PHP，TTFB 从 120ms 涨到 400ms。后来换成 LiteSpeed Cache 并启用服务器级缓存，TTFB 降到 35ms。教训是：换服务器后必须重做缓存方案，配置不能照搬。
- LiteSpeed Cache 的 Crawler 配置过猛。并发和间隔设置不当会把自己的站点爬出高负载，小站建议低并发、长时间间隔。
- QUIC.cloud 配额用完没察觉。图片优化突然失效，需要去 QUIC.cloud 后台看配额。
- ESI 开了但主题不支持。WooCommerce 下启用 ESI 前要确认主题兼容，否则购物车小部件不更新。
- 只看首页速度。分类页、搜索页、单页的缓存命中率往往比首页低，要分别验证。
总结
选型逻辑一句话：服务器是 LiteSpeed 就用 LiteSpeed Cache，是 Nginx/Apache 就用 WP Rocket（或免费的同类方案），永远不要在同一站点上同时开两个缓存插件。预算只是次要因素——LiteSpeed Cache 免费但依赖 QUIC.cloud，WP Rocket 付费但自包含。决定之后，用 curl -I 验证命中头，用多次 TTFB 取平均，比任何主观感受都可靠。
选定之后，LiteSpeed Cache 插件完整配置教程 和 WP Rocket 配置全解析 分别给出两套方案的详细配置清单。
