登录 WordPress 后页面看起来一切正常，退出登录或打开无痕窗口，却看到旧内容、缺失的样式，甚至失灵的手机菜单。先不要把原因直接归给 LiteSpeed Cache，也不要急着全站清缓存。登录与访客的差异只是线索：两种请求可能拿到不同的页面缓存、不同的 CSS/JS 优化结果，还可能经过浏览器或 CDN 的缓存。
证据边界（2026 年 10 月 31 日）：本文结合 LiteSpeed 与 Cloudflare 官方文档、公开社区报告，以及 DocsHook 在完全隔离的本地站进行的一项受控实验。我们复现的是“登录用户看到新内容，匿名访客命中旧 HTML”；用来表示差异的是测试页上的 v1/v2 文本，而非真实的 CSS 错版。我们没有复现 UCSS 漏选、Guest Optimization、Cloudflare 边缘缓存故障，也没有在 DocsHook 正式站制造故障。下文把这些情况作为不同的排查分支，不把它们写成我们的实测结论。
本文目录
- 适用范围：WordPress 登录正常、访客页面错版
- 清理 LiteSpeed 缓存前，先保留访客错版证据
- 比较登录、首次匿名和重复匿名访问，定位页面差异
- 只修复已确认的缓存、页面优化或资源问题
- DocsHook 的隔离实验：只证明旧公开 HTML 分支
- 修复后复测匿名访客、手机布局与缓存状态
- LiteSpeed 官方资料与尚未实测的故障分支
适用范围：WordPress 登录正常、访客页面错版
这套方法适合安装 LiteSpeed Cache for WordPress（LSCWP）的网站：后台或登录前台正常，匿名页面却显示旧内容、错位布局、缺失 CSS，或手机首次访问与刷新后不同。具体菜单和缓存能力取决于插件版本、Web 服务器、主题、Cloudflare 规则及已启用的优化选项。登录用户也可能使用 LiteSpeed 的私有缓存，因此“我已登录”不等于“完全没有缓存”。
如果你发现登录页被公开缓存、私人资料出现在其他访客页面，或用户权限出现异常，应将它视为安全问题，先保存证据并联系主机或 CDN 支持，不要按普通排版故障继续试开关。
清理 LiteSpeed 缓存前，先保留访客错版证据
记下出问题的准确 URL、时间、浏览器、设备宽度、是否登录，以及最近一次内容、主题、插件或缓存设置变更。在相同宽度下分别截图登录和匿名页面。打开浏览器开发者工具的 Network 面板，记录页面文档和失败的 CSS/JS 请求：状态码、请求 URL、响应头与控制台错误。保存证据时去掉 Cookie、后台 nonce、客户资料及私人链接。
特别区分两类响应头：页面文档上的 X-LiteSpeed-Cache 说明源站 LiteSpeed 是否报告缓存命中；文档和静态资源上的 CF-Cache-Status 用于判断 Cloudflare 的处理状态。hit 只说明响应来自某层缓存，不证明内容是新的；某个头不存在，也不能单凭这一点排除其他缓存。浏览器本地缓存还需要单独检查。
比较登录、首次匿名和重复匿名访问，定位页面差异
比较登录、首次匿名和重复匿名
对同一个 URL 依次查看：登录状态、全新无痕会话的第一次访问、同一匿名会话刷新后的再次访问。逐次记录页面内容、文档响应头，以及关键 CSS/JS 是否成功加载。如果仅首次匿名访问异常，应检查 Guest Mode／Guest Optimization 和首屏资源；如果重复访问才显示旧版，应优先怀疑公开 HTML 或资源引用仍在缓存。它们是待验证的方向，不是从症状直接得出的根因。手机问题还要在同一宽度下重做这组比较。
记录完三次访问，按实际差异决定下一项检查，而不是同时改多个开关：
- 登录页面是新版、匿名 HTML 是旧版，且匿名文档显示
X-LiteSpeed-Cache: hit：先比较不读取页面缓存时的应用输出，再检查该 URL 的公开页面缓存及失效机制。 - HTML 内容正确，但 CSS/JS 请求返回 404、旧文件或控制台报错：沿着页面引用的资源 URL 查源站、浏览器及 CDN，不要只清 HTML 缓存。
- 仅首次匿名访问异常，随后刷新正常：在隔离站核对 Guest Mode／Guest Optimization 和首屏资源；这只是排查方向，仍需请求与资源证据确认。
单独比较页面优化
LiteSpeed 的 CSS/JS 排障指南建议，在匿名窗口给受影响 URL 加上 ?LSCWP_CTRL=before_optm（原 URL 已有查询参数时使用 &），观察绕过 LSCWP 页面优化后的效果。如果页面恢复，继续比较优化前后的 CSS/JS 文件、选择器与加载顺序；如果仍然异常，就检查旧 HTML、CDN／浏览器资源、主题插件或源站错误。这个参数不是 Cloudflare、浏览器及所有源站缓存的通用绕过开关；前面有 CDN 时，还要确认请求实际到达了准备比较的层。
看失败的对象，而不只看视觉结果
CSS 文件返回 404、旧 HTML 指向已不存在的生成文件、CSS 请求成功但缺少选择器、JavaScript 抛异常，是四种不同问题。分别检查文档与资源的 URL、状态码和缓存头。手机菜单点不动也不能直接断定是 JS 合并；公开的一个 GeneratePress 支持案例最终指向异步 CSS。该案例说明应检查实际失败资源，不能代替你的网站测试。
只修复已确认的缓存、页面优化或资源问题
修改设置前，记录或导出当前 LSCWP 配置，并确认有可恢复备份。优先在隔离站试；生产站需要修改时，一次只调整一项，再清理与之相关的缓存，复测首次和重复匿名请求。如果确认是某个 CSS/JS 优化选项，先停用该项或排除具体文件。若证据指向 UCSS 缺少选择器，比较原始与生成样式后再考虑 Allowlist。LiteSpeed 工具箱文档说明，普通 Purge All 不会清除 Unique CSS；确需重生 UCSS 时应使用对应的单独清理入口，并考虑生成配额。
如果旧 HTML 仍引用过期资源，先定向清除受影响的 LiteSpeed 页面，并确认下一次匿名访问为正确的 miss、再下一次 hit 仍正确。若 Cloudflare 提供了旧对象，按其缓存响应说明找准对象，再按定向清理建议处理相应 URL 或资源。浏览器强制刷新只能帮助识别本地缓存，不能替其他访客修复页面。不要因为故障只在手机出现，就盲目启用独立手机缓存；也不要在未找到原因前永久停用整个插件。
如果一次修改让页面更糟，恢复原设置，清理该修改影响的缓存，并复测修改前的状态。不要在生产站为“证明故障”执行恢复演练。
DocsHook 的隔离实验：只证明旧公开 HTML 分支
2026 年 10 月 31 日，我们在仅本机可访问的测试环境使用 WordPress 7.1.4、GeneratePress 3.6.1、LiteSpeed Cache 7.9.2、OpenLiteSpeed 1.9.2 和 PHP 8.3.33。测试不含 Cloudflare 或真实访客资料；公开页面缓存开启，登录用户缓存、Guest Mode、Guest Optimization 及 CSS/JS 优化关闭。一个测试短代码根据 WordPress 选项显示 “Old layout (v1)” 或 “Current layout (v2)”。这只是可见内容的代理，不是 CSS 故障。
先让匿名访客访问测试页，响应从 X-LiteSpeed-Cache: miss 变为 hit，两次都显示 v1。随后我们只用 WP-CLI 更新该测试选项，没有走普通文章编辑及其缓存失效钩子。登录访问动态显示 v2，同一 URL 的匿名访问仍为缓存 hit 且显示 v1；本地允许的 LSCWP_CTRL=NOCACHE 诊断请求显示 v2 和 no-cache。这组响应把当前应用输出与旧公开 HTML 区分开来。该诊断命令是否可用取决于站点的 Admin IP Commands 配置，不应直接照搬到生产站。
通过 LiteSpeed Toolbox 清理测试站的 LSCache 后，匿名首次 miss 与重复 hit 都显示 v2。我们再导入故障前的本地数据库快照并清理测试缓存，匿名请求恢复为显示 v1 的 miss→hit。这验证了测试页可见标记和访客缓存行为的回退；没有验证 HTML 每个字节完全相同，也不是生产站恢复测试。实验更不说明普通 WordPress 文章保存会漏清缓存。桌面与 390px 手机截图、脱敏响应头和操作顺序保存在 DocsHook 的研究档案；本文暂采用无图排版。
这个实验里，触发旧页面的条件是我们故意绕过普通编辑流程更新了选项，没有触发相应的页面缓存失效。清理缓存只让当时的访客页面恢复正确；如果实际业务会以同样方式改变页面输出，持久修复还需在数据变化时定向清理相关缓存，或让真正动态的内容不进入公开页面缓存。本文没有验证任何生产站的失效钩子。
修复后复测匿名访客、手机布局与缓存状态
用发现问题时同一组条件回测：登录、首次匿名、重复匿名；桌面与手机宽度；故障页面及至少一个未受影响的页面。确认预期 HTML、CSS/JS 文件与手机菜单正常，Network 没有新的失败请求，控制台没有相关错误，并分别记录 LiteSpeed 与 Cloudflare 的缓存头。一次“清缓存后看起来好了”只能证明症状暂时消失；如果状态变化仍不会触发正确的失效，旧页面还可能回来。
常见误判包括：把“后台正常”当作访客正常；把 Purge All 后恢复当作根因已经找到；把所有手机问题归给手机缓存开关；以及只看性能分数、不看真实交互或首次访问。先保存证据，再让每一步改动回答一个具体问题。
LiteSpeed 官方资料与尚未实测的故障分支
功能定义和操作边界以 LiteSpeed 官方的缓存设置、CSS/JS 排障、页面优化设置、Guest Optimization 说明及工具箱文档为准；Cloudflare 层参照其缓存响应和定向清理文档。以上资料于 2026 年 10 月 31 日核对。
社区报告只证明有人遇到类似症状及其自述结果：一则 WordPress.org 案例称停用 Generate UCSS 并清缓存后恢复；另一则 WordPress.org 案例称清除 Cloudflare 缓存后恢复，但未证实具体哪个对象过期；一则 Reddit 报告描述手机 CSS 间歇异常，根因未确认。它们不能作为 DocsHook 测试结果，也不能代替你的请求头和资源记录。
DocsHook 尚未在隔离环境复现 UCSS 漏选、Guest Optimization 首次访问差异或 Cloudflare 边缘旧对象。有关这些分支的步骤目前是官方说明和社区报告驱动的诊断建议。想了解我们的证据与编辑原则，可阅读关于 DocsHook；其他主题见中文指南。英文原文：Why Your WordPress Site Looks Fine Logged In but Broken for Visitors。