本文约 3,609 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：装完 LSCache，命中率一直是 0%
LiteSpeed Cache（简称 LSCache）是 LiteSpeed 生态里最有价值的免费插件，也是公认”配置项最多的缓存插件”。它的菜单分了十几个标签页，每个页面里二三十个开关，很多站长装完启用就以为完事了，结果去后台一看：缓存命中率 0%，页面照样慢。
原因通常是三件事：没在 LiteSpeed 服务器层面启用缓存（OLS 需要在虚拟主机配置里开启 cache 模块并指定存储路径）；默认缓存策略把登录用户和有 Cookie 的请求全部排除了（这在很多站点上等于把大部分流量排除掉）；爬行器没配，冷启动全是未命中。本文按板块把该动的和不用动的区分开。
原理分析：LSCache 的工作方式与六个板块
LSCache 和 WordPress 通信靠的是响应头。插件在 PHP 侧输出 X-LiteSpeed-Cache-Control 头，告诉 Web 服务器”这个页面可以缓存多久、按什么维度区分缓存”；Web 服务器收到后把响应存进自己的缓存池，下次请求直接返回，不再调用 PHP。
六个板块的作用与风险：
| 板块 | 作用 | 推荐 |
|---|---|---|
| Cache | 页面缓存开关、TTL、浏览器缓存、缓存排除 | 必配 |
| Object | 对象缓存（Redis/Memcached） | 有 Redis 就配 |
| Page Optimization | CSS/JS 压缩合并、CCSS 生成、延迟加载 | 收益中，风险中 |
| Image Optimization | 通过 QUIC.cloud 转 WebP、压缩 | 推荐，注意配额 |
| CDN | QUIC.cloud CDN / CDN 映射 | 按需 |
| ESI | 整页缓存下的局部动态块 | WooCommerce/会员站才配 |
| Crawler | 预热缓存 | 小站推荐 |
其中 ESI（Edge Side Includes）是最容易被误解的：它的作用是让一个整页被缓存的同时，页面里的某几个小块保持动态。典型场景是 WooCommerce——商品详情页可以整页缓存，但顶部的”购物车（3 件）”小部件必须实时更新。开了 ESI 之后，这个小部件会被替换成一个 ESI 占位块，由服务器单独请求生成。
保姆级实操
第一步：确认服务器侧已启用缓存
# 看响应头里有没有 LSCache 相关字段
curl -sI https://mimangfei.com/ | grep -iE 'x-litespeed|cache-control'
# OLS 的虚拟主机配置里应有类似片段
grep -R "cacheRoot\|CacheLookup\|module cache" /usr/local/lsws/conf/vhosts/ 2>/dev/null | head
OpenLiteSpeed 需要在 vhost 配置里设置缓存根路径并启用：cacheRoot /usr/local/lsws/cachedata/$VH_NAME。
第二步：基础缓存配置
进入 LiteSpeed Cache → Cache → Cache：
- Enable Cache：On；
- Cache TTL（Default Public Cache TTL）：
604800（7 天）比较合适； - Cache Logged-in Users / Commenters：普通站点关；
- Cache REST API、Cache Login Page：关。
浏览器缓存标签页：Browser Cache On，TTL 设 31557600（一年），并开启 Add Expires Headers。
排除（Excludes）标签页：把 WooCommerce 的 cart、checkout、my-account 加入 Do Not Cache URIs。
第三步：页面优化（谨慎逐项）
Page Optimization → CSS Settings：
- CSS Minify：On；CSS Combine：Off（HTTP/2 下无收益）；
- Generate Critical CSS（CCSS）：On（需要 QUIC.cloud 配额），生成后前台检查是否出现 FOUC（样式闪动）；
- Load CSS Asynchronously：谨慎，和 CCSS 配合才行。
JS Settings：JS Minify On；JS Defer On；JS Combine Off。
第四步：图片优化
Image Optimization → Image Optimization Settings：
- Auto Request Cron：On；
- Auto Pull / Auto Crawler：On；
- Optimize Original Images / Remove Original Backups：先关，确认效果后再决定是否删原图；
- 之后点 Send Optimization Request，去 QUIC.cloud 后台绑定站点（免费配额有限）。
# 确认图片优化结果
curl -sI https://mimangfei.com/wp-content/uploads/2026/01/demo.jpg | grep -iE 'content-type|x-litespeed'
第五步：ESI（按需）
LiteSpeed Cache → Cache → ESI：ESI On；再在 WooCommerce 标签页启用 Cart ESI。注意：ESI 需要服务器支持，OLS 需在 vhost 里启用 ESI 模块。
第六步：爬行器预热
LiteSpeed Cache → Crawler → General Settings：
- Crawler：On；
- 到 Cron 或 Map 标签页，把站点地图地址填进去：
https://mimangfei.com/wp-sitemap.xml； - Sitemap Generation 标签页可以设置并发数与间隔，小站保持默认即可。
第七步：对象缓存（可选但收益高）
# 确认服务器有 Redis
redis-cli ping
# 在 wp-config.php 里声明
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_CACHE', true );
然后到 LiteSpeed Cache → Object 里确认状态变为 “Enabled”。
第八步：验证与清缓存
curl -sI https://mimangfei.com/ | grep -i 'x-litespeed-cache'
# 期望：x-litespeed-cache: hit（第二次请求起）
wp litespeed-purge all 2>/dev/null || \
wp cache flush
常见踩坑
- OLS 上没启用 cache 模块，插件怎么配都不命中。
- CCSS 生成导致样式闪动。首屏出现无样式内容（FOUC），需要调整 CCSS 或关闭异步加载 CSS。
- QUIC.cloud 配额耗尽。图片优化静默失效，去 QUIC.cloud 后台查看每日配额。
- 爬行器并发过高。小站被自己的爬行器爬出高负载，CPU 长期 100%。
- 案例：一个会员站开了 LSCache 之后，所有登录用户看到的都是别人的账户名。原因是”Cache Logged-in Users”被打开了，且 ESI 没配置，导致带用户 Cookie 的页面被当作公共缓存返回给别人。修复是立刻关闭该选项、清全部缓存，并为会员区域配置 ESI 私有块。
- 删了原图备份后无法回滚。图片优化是不可逆的，务必先跑一次完整备份。
- 和 Cloudflare 等 CDN 的缓存层叠加，改了内容后要同时清两边，否则出现”清了缓存页面没变”。
总结
LiteSpeed Cache 的配置顺序应该是：先确认服务器侧缓存已启用 → 配 Cache 基本项与排除 URI → 配爬行器预热 → 再考虑页面优化与图片优化 → 最后才是 ESI 和对象缓存。每一步都用 curl -I 看 x-litespeed-cache 头确认状态，不要凭后台显示判断。特别提醒：登录用户缓存和 ESI 是高风险的联动选项，会员站务必先关再测。
选型阶段可以参考 WP Rocket 与 LiteSpeed Cache 怎么选；图片优化之外，Autoptimize 合并压缩 CSS/JS 的正确姿势 也能补上前端优化这一环。
