上一篇把域名解析指向了 Cloudflare，也在 LiteSpeed Cache 里完成了 CDN 切换。但这时候博客还有两个问题没解决：Cloudflare 免费版默认不缓存 HTML 页面，以及 LiteSpeed 里一部分依赖 QUIC.cloud 云端额度的功能因为额度不足会出问题。这一篇就是把这两件事一个个排查清楚。
为什么还需要装一个插件
Cloudflare 免费版默认只缓存图片、CSS、JS 这类静态资源，不缓存 HTML 页面。如果什么都不做，访客每次打开博客文章，请求还是会回源到真实服务器去生成页面，Cloudflare 在这一层就没有真正发挥作用。
解决办法是装一个免费插件：Super Page Cache for Cloudflare。它会通过 API 在 Cloudflare 后台自动配置缓存规则，让 HTML 页面也被缓存到边缘节点，同时足够聪明，能自动识别登录用户和发表评论的访客，给他们绕开缓存，避免后台或者评论功能错乱。
如果不用这个插件，单纯在 Cloudflare 后台手动开启”缓存所有内容”，确实也能让 HTML 被缓存，但需要自己手动配置规则去排除带登录 Cookie 的请求（比如 /wp-admin/ 路径），稍有疏漏就会导致后台或登录状态显示异常。用插件能省掉这一步的麻烦。
安装方法很简单：WordPress 后台 → 插件 → 安装插件，搜索 Super Page Cache for Cloudflare，安装并启用。然后进入插件设置页面，填入 Cloudflare 账号邮箱和 API 令牌（跟上一篇里 LiteSpeed 用的那个令牌可以是同一个），选择域名，保存，再点击”Enable Page Caching”开启页面缓存。
LiteSpeed 页面优化：哪些要关，哪些能留
这一部分是排雷的重点。因为 Page Optimization 的额度已经用完，LiteSpeed 里依赖云端生成的功能继续开着不会报错变好看，只会因为请求不到云端资源而导致页面样式缺失或者排版错乱。下面按照功能本身是”本地处理”还是”云端处理”来分类。
| 设置项 | 处理方式 | 建议 |
|---|---|---|
| CSS 最小化 / JS 最小化 | 本地 | 保持开启 |
| CSS 合并 / JS 合并 | 本地 | 建议关闭（容易导致多语言或结构复杂的页面排版错乱） |
| 生成 CCSS / UCSS（关键 CSS） | 云端 | 必须关闭 |
| UCSS 内联 | 云端 | 必须关闭 |
| 异步加载 CSS | 云端 | 必须关闭 |
| 内联 CSS 异步库 | 云端 | 必须关闭 |
| 延迟加载 JS | 本地 | 可以保持开启（如果发现交互异常再关） |
| 图片懒加载 | 本地 | 保持开启 |
| 字体显示优化（Swap） | 本地 | 保持不变 |
判断标准其实很直观：凡是名字里带”生成””异步加载云端样式”这类描述的功能，基本都要靠 QUIC.cloud 的服务器算出结果再传回来，额度不够就会卡住或者报错。而”最小化””合并”这种单纯的代码压缩、拼接，是本地服务器自己就能完成的，跟额度没关系。
CSS 合并和 JS 合并单独说一下：这两个本身不耗云端额度，但实际效果上容易把不同页面所需的样式或脚本强行打包成一个文件，如果博客有多语言版本或者结构差异较大的页面，合并之后某些页面可能会出现布局错位。出于稳妥考虑，这次选择直接关闭。如果博客结构单一、页面之间高度统一，也可以保留开启试一下效果。
图片优化：额度还有余量的话，不用动
这是容易被一并误伤的一项。QUIC.cloud 的额度是分项计算的，Page Optimization 用完了，不代表图片优化的额度也用完了。如果检查后发现图片优化那部分还剩不少，完全可以继续让它跑：
- 自动请求优化（Auto Request Cron）：保持开启
- 自动推送到云端（Auto Pull Cron）：保持开启
这样新上传的图片依然会被发送到 QUIC.cloud 云端做无损压缩并生成 WebP 格式，压缩完的图片存回自己的服务器，再通过 Cloudflare 分发给读者——相当于用 QUIC.cloud 还有余量的额度做图片瘦身，用 Cloudflare 的免费流量做加速分发，两边各自发挥所长。
但如果检查后发现图片优化额度也已经用完或者快用完了，那就要把这两个开关也关掉，否则插件会持续在后台尝试发送注定失败的请求，白白消耗服务器资源。
数据库优化：不用碰
数据库清理（清理文章历史版本、垃圾评论、优化数据表）完全在本地服务器运行，跟 CDN 选择和云端额度都没有关系。这部分保持原有的使用习惯就行，不需要因为这次调整做任何改动。
两个插件如何分工，不互相打架
装完 Super Page Cache for Cloudflare 之后，WordPress 后台大概率会弹出一个提示：”Multiple Caching Plugins Detected”（检测到多个缓存插件），提醒同时启用了 LiteSpeed Cache。这个提示本身没说错——正常情况下确实不建议同时开两个缓存插件，因为它们会抢着生成本地缓存，容易冲突。
但这里的情况不一样：两个插件的职责已经被刻意分开了，并没有重叠。
| 插件 | 负责的事情 |
|---|---|
| LiteSpeed Cache | 本地服务器端的代码压缩、图片处理、本地数据库维护 |
| Super Page Cache for Cloudflare | 调度 Cloudflare 边缘节点的页面级缓存，登录/评论用户自动绕过缓存 |
为了避免重叠，在 Super Page Cache for Cloudflare 的设置里，建议把所有跟前端代码优化相关的选项都保持关闭，比如 HTML 最小化、谷歌字体优化、资源管理器，把这部分工作完全留给 LiteSpeed 去做。同样，懒加载相关的选项也保持关闭，因为 LiteSpeed 那边已经在处理图片懒加载了。
真正需要打开的是插件里 LiteSpeed Cache settings 这一组联动选项，作用是当 LiteSpeed 在本地清除某类缓存时，让 Super Page Cache 同步去清理 Cloudflare 对应的缓存。这里最值得留意的是”单篇文章缓存通过 API 刷新”这一项：开启之后，修改某一篇旧文章时，只有那一篇文章在 Cloudflare 节点上的缓存会被刷新，博客里其他几百篇文章依然保持缓存状态，不会因为改了一篇文章就让全站缓存失效，CDN 命中率能维持在比较高的水平。
看到那条提示后，直接关掉就行，不需要纠结。两个插件目前是在配合，不是在抢工作。
改完之后，记得清一次缓存
所有设置调整完毕后，鼠标悬停在 WordPress 后台顶部的 LiteSpeed 图标上，点击”全部清除”。因为已经绑定了 Cloudflare API，这一次操作会同时清空本地服务器缓存和 Cloudflare 边缘节点上的旧缓存，确保接下来访客看到的都是最新配置下生成的页面。
这一篇把插件层面容易冲突的细节都过了一遍。下一篇是验收阶段：怎么用浏览器开发者工具确认缓存是不是真的命中了 Cloudflare，以及遇到标头显示不对时该往哪几个方向去排查。
系列文章：把博客缓存迁移到 Cloudflare
