1 WordPress 缓存困局与解决思路

1.1 为什么很多Wordpress站长宁愿放弃 CDN？

在静态站点的世界里，CDN 几乎是“白送的性能优化”：静态文件天然适合缓存，HTML 页面也几乎不会频繁更新，因此只要将资源推送到 CDN 节点上，就能立刻收获极低的延迟和极高的并发能力。对前端开发者或静态博客用户而言，开启 CDN 没有什么成本，收益却是立竿见影。

但对于 WordPress 这样典型的动态站点来说，情况就完全不同了。很多站长明明知道 Cloudflare 提供免费 CDN，却依然选择直接用 VPS 裸跑网站，理由大致有以下几点：

1. 缓存不同步带来的挫败感

WordPress 内容更新频繁，比如写博文、改页面、调样式，甚至读者留言。假如 CDN 缓存规则配置不当，就会出现“前端还在显示旧版本”的情况。对站长来说，最难受的莫过于：自己辛辛苦苦更新了一篇文章，结果访客依然只能看到老内容。

2. 动态内容处理复杂

登录态、评论、购物车、个性化内容，这些都无法简单地缓存。站长需要设置绕过规则，但规则太松又失去了缓存意义，规则太严又容易误伤，最后很可能陷入一个“怎么调都不顺手”的尴尬境地。

3. 直接用 VPS 更加可控

许多站长会选择给 VPS 装上缓存插件(比如本地页面缓存、对象缓存)，虽然不能覆盖全球，但至少结果可预期、问题可排查。相比之下，依赖 CDN 意味着多了一层黑盒，出了问题可能既不是服务器的问题，也不是 WordPress 的问题，而是 CDN 节点的缓存不一致，排查成本极高。

4. 运维心态的差异

站长们普遍更倾向于稳定而不是折腾，CDN 对静态站点是“锦上添花”，但对动态站点却可能变成“添乱”。因此不少人干脆走“最小依赖”的思路：服务器性能够用、带宽撑得住，就不折腾 CDN，把时间精力放到内容和功能上。

因此，WordPress 站长普遍对 CDN 持谨慎态度，哪怕 Cloudflare 的免费方案看起来诱人，也会有人选择“弃而不用”。要想真正让 WordPress 和 CDN 结合，解决缓存不同步的问题才是关键。

1.2 Cloudflare 官方 APO：WordPress 的最佳实践方案

在讨论第三方插件之前，我们不得不先提到 Cloudflare 自家的 APO(Automatic Platform Optimization)，这是 Cloudflare 专门为 WordPress 打造的一套优化方案，可以说是目前 WordPress 全站缓存管理的“官方最佳实践”。

APO 的核心思路很简单：把 整个 WordPress 站点的 HTML 页面也纳入 CDN 缓存，并通过智能的缓存刷新机制，确保文章更新后，全球 Cloudflare 节点能够尽快获得最新的内容。相比于传统的 CDN 只缓存静态资源（图片、JS、CSS），APO 直接解决了 WordPress 这种动态站点 “HTML 无法全站缓存” 的老大难问题。

更重要的是，APO 的体验几乎是“无感”的：

• 智能缓存刷新：当文章或页面更新时，Cloudflare 会自动调用接口刷新对应缓存，避免手动清理缓存的繁琐操作。
• 移动端优化：APO 内置了针对移动设备的缓存与响应优化，减少移动用户访问的延迟。
• 边缘节点加速：无论访客来自哪里，APO 都会优先从离用户最近的 Cloudflare 节点直接返回缓存的 HTML，大幅降低 TTFB（首字节时间）。
• 开箱即用：WordPress 官方插件与 Cloudflare 紧密配合，站长几乎不需要复杂配置，就能获得完整的加速效果。

换句话说，开启 APO 后，WordPress 站点的访问体验在 CDN 层面上几乎和静态站点没有差别，既能享受到全站缓存带来的速度优势，又能保持文章更新的实时性，这也是很多站长称它为“完美方案”的原因。

不过，美中不足的是：费用问题：APO 对于 Free 用户需要额外支付 5 美元/月，而 Pro 套餐（20 美元/月）及以上 才会免费附带。这让很多小型个人博客站长望而却步；绑定生态：APO 是 Cloudflare 自家的闭环服务，如果你打算迁移到其他 CDN 或者采用自建方案，就没法继续使用。

因此，虽然 APO 在技术层面几乎无可挑剔，但它的门槛并不低。很多 WordPress 用户在了解之后，依旧选择观望，或者退而求其次寻找第三方插件来实现类似的功能——这也就为后续的各种免费的替代方案留下了空间。

1.3 乞丐版APO方案已不再受Cloudflare官方支持

在之前的文章中，我介绍过一种通过 Cloudflare Worker 来实现“乞丐版 APO”功能的方案(参见文章：家庭数据中心系列 cloudflare教程(七) CF worker功能介绍及基于worker实现”乞丐版APO for WordPress”功能加速网站访问的实操、验证及相关技术原理研究)。该方案的原理是：借助一个免费的 WordPress 插件，配合运行在 Cloudflare Worker 上的 JS 脚本(基于 Cloudflare 官方曾经提供的 edge-cache-html.js 示例脚本修改而来)，来实现 WordPress 动态内容的静态化缓存。同时，插件还能在站点内容更新时，自动触发对 Cloudflare 缓存内容的版本管理，从而保证缓存始终与实际内容同步。

不过，这个“乞丐版 APO”方案一直让我觉得不够理想，原因主要有两点：

1、Cloudflare 已不再提供官方支持

github上cloudflare的官方仓库已经移除了该插件的下载：

虽然我当时将插件备份到了我的资源站里，但由于该插件多年没有更新，我无法保证它能在当前版本的 WordPress 上正常工作，更不用说安全性隐患了。与此同时，GitHub 上的 cloudflare/templates 仓库中也不再提供 edge-cache-html 模板目录，之前：

现在：

可见cloudflare已经完全不提供对这种方式的官方支持了。

2、免费订阅用户的限制较多

即便仍然使用该方案，对于 Cloudflare 免费计划的用户来说，也会面临 Worker 的限制：每天只有 10 万请求额度，而且还需要额外配合 KV 存储。虽然 KV 的免费额度在理论上足够个人使用，但在实际部署过程中，我遇到过不少“误报”或异常，体验并不稳定。

更重要的是，随着我自己长期使用 APO 功能，对缓存与加速的要求也越来越高。相比之下，这套“乞丐版 APO”方案略显简陋，不足以支撑一个稳定、可持续的站点加速体系。因此，在很长一段时间里，我始终没有找到一个既能适配 Cloudflare 免费订阅用户，又能实现自动化缓存管理和加速的理想方案。

那么，什么样的方案才算“比较完美”呢？如果参照 APO 的标准，至少需要满足：

• 仅需在 WordPress 本地安装一个插件；
• 不需要配置复杂的 Worker与 KV 存储；
• 能够在内容更新时，自动刷新并管理 Cloudflare 的缓存版本；
• 具备稳定的兼容性与持续维护。

而最近发现的一个wordpress插件：”Super Page Cache“，正好在这些方面给出了一个接近理想的解决方案。

2 Super Page Cache插件介绍

2.1 传统的WordPress本地缓存插件的痛点

传统的本地缓存插件，比如 WP Super Cache、W3 Total Cache、WP Fastest Cache，以及功能更全面的 LiteSpeed Cache，它们的核心思路都是一样的：在服务器端提前生成页面的静态副本，然后由 Web 服务器(如 Nginx、Apache、LiteSpeed)直接返回给访客。这样就避免了每次都让 WordPress 去动态解析 PHP、执行数据库查询，大大降低了后端的压力。

这类本地缓存插件有一个天然的前提：站点需要直接通过 VPS 公网地址对外发布。缓存文件虽然能保存在本地磁盘，但最终还是依赖 VPS 上的 Web 服务器来响应请求。换句话说，它们的优化范围主要停留在 源站层面，而不是 CDN 级别的缓存。

实际效果就是：当请求回源到达服务器时，Web 服务器会优先命中本地缓存文件，避免 PHP 动态解析和数据库查询，从而显著降低后端压力。但页面能否被缓存到 CDN 边缘节点，却完全取决于 CDN 自身的策略。以 Cloudflare 为例，它默认不缓存 HTML 内容，除非用户自己去写规则。

问题也就出在这里：本地缓存插件无法和 Cloudflare 建立联动。当你更新文章时，本地缓存虽然会被清理，但 Cloudflare 边缘节点的缓存可能依旧存在，最终导致“源站和 CDN 缓存内容不同步”。要解决这个问题，通常只有两种办法：手动到 Cloudflare 仪表盘清理缓存，或者干等缓存过期。

2.2 与众不同的Super Page Cache插件

在 WordPress 的世界里， Super Page Cache for Cloudflare(简称 SPC)是一个非常特别的存在：它并不是单纯意义上的“本地页面缓存工具”，它的特别之处在于，它可以做本地缓存，也能通过与 Cloudflare 的 API 联动，确保边缘缓存和本地内容保持同步，从而实现类似 APO 的全球加速效果。这种方式，几乎复刻了 Cloudflare APO 的效果，对于不想为 APO 付费的用户来说，它算得上是最接近理想的替代方案。

要理解 SPC 的特别之处，先得回到 APO 的设计思路。传统情况下，Cloudflare 在边缘节点主要缓存的是静态资源，比如 JS、CSS 和图片文件，而 WordPress 页面本身仍然是动态生成的，每次请求都要回源到服务器进行解析和数据库查询。APO 的创新点就在于，它把 WordPress 生成的 HTML 页面也纳入缓存体系，让这些原本需要动态生成的内容在边缘节点直接提供。

换句话说，APO 会将动态页面“静态化”，并在全球 Cloudflare 节点上缓存副本，从而大幅减少回源请求。更重要的是，APO 并不是一个单向的缓存，它与 WordPress 之间保持着联动：当站点内容发生更新，比如文章被新增或者修改、页面被删除或者评论被新增时，WordPress 插件会主动调用 Cloudflare 的接口，通知边缘节点清理或刷新对应的缓存。这样一来，缓存命中率和内容时效性之间达成了平衡，访客看到的永远是最新的页面，而访问速度却接近一个纯静态站点。

SPC 插件正是沿着这一思路来设计的：它通过 Cloudflare 的 API 与Cloudflare边缘网络建立联动。当你在后台发布、更新文章，或者调整站点内容时，SPC 会自动调用 API，通知 Cloudflare 清理或刷新相关页面的缓存。换句话说，缓存的存储动作依赖于 Cloudflare 的缓存规则，而 SPC 的作用在于保证缓存与站点内容同步。这样一来，站长几乎不需要手工干预，就能让页面缓存保持最新状态，实现了高度的自动化与无感化。

与之前那种“乞丐版 APO”方案相比，SPC 带来的改变非常明显：首先，它完全不依赖 Worker，因此也就摆脱了每日请求数和 KV 读写限制的困扰。其次，它是一个仍在持续更新的插件，在 WordPress 插件库中保持活跃，意味着兼容性和安全性都有保障。而且，它的配置非常简单，只需要在插件设置里填写一组 Cloudflare Global API Key(或者API Token)，基本就能实现和Cloudflare的缓存联动了。

在实际使用中，SPC 的效果整体还算不错。它能把 WordPress 的 HTML 页面推送到 Cloudflare 节点缓存中，从而减少回源压力，让访问速度有一定提升。但需要说明的是，它的体验和 APO 还是有明显差距的：刷新缓存的生效速度不够稳定，有时需要等待几分钟甚至更久，尤其在使用 Cloudflare 免费套餐时表现更明显。

插件本身也提供了一些常见的灵活选项，比如可以设置哪些页面参与缓存、哪些页面需要排除，从而避免关键动态页面被缓存干扰。这些功能让站长可以更细致地控制缓存范围，避免“一刀切”的情况。

总体来说，Super Page Cache 更像是一个 实用的替代方案：它无法完全取代 APO，但对于使用 Cloudflare 免费套餐、又希望借助边缘缓存改善访问体验的站点来说，依然有一定价值。需要注意的是，它并不是“开箱即用的完美方案”，一些动态页面（如购物车、登录后台等）仍然需要通过排除规则来保证功能正常。好在 SPC 可以自动为常见动态内容生成相应的缓存排除规则，这在一定程度上减轻了站长的手动配置负担，但仍建议结合实际需求进行调试和验证。

如果用一个比喻来理解：APO 就像为 WordPress 量身定制的“全自动边缘缓存管家”，几乎无需干预就能保证缓存即时同步、浏览器缓存处理到位、动态页面兼容性好；而 SPC 更像一位“半自动助理”，虽然能够自动同步文章更新到 Cloudflare 并提供手动操作选项，但在缓存刷新延迟、浏览器缓存控制以及特殊动态页面兼容性上仍有一定局限。换句话说，如果你追求“开箱即用、极致体验”，APO 是首选；如果你是免费套餐用户或希望完全掌控缓存逻辑，SPC 则提供了一个灵活、可行的替代方案。

3 Super Page Cache的安装及设置

3.1 插件安装及激活

安装完成后启用插件：

激活插件的缓存功能：

激活成功：

3.2 插件设置

3.2.1 概述

进入设置界面后，可以看到有5个选项区域：

3.2.2 General:Core configuration(本地缓存功能设置)

这部分区域是Super Page Cache 的核心配置区域，主要决定插件的本地缓存开关和全局规则。它提供了几个关键功能：是否启用本地磁盘缓存、对特定 Cookie 或 URL 路径跳过缓存的控制，以及对营销参数的统一处理（Pro 功能）。这些选项保证了在提升页面速度的同时，不会影响到用户的动态操作或敏感接口。除此之外，还可以选择是否显示高级设置，方便对缓存逻辑有更细化需求的用户进行扩展：

“高级设置”部分其实很很多非常实用的选项，但是选项太多了，我懒得一一解释，就把翻译界面截个图大家自己看看吧：

---

重要提醒：

“General: Core configuration” 功能区主要用于设置 SPC 的 本地缓存功能。虽然它和 Cloudflare 边缘缓存属于不同层级，但并不是非此即彼的关系。启用本地缓存后，VPS 主机会在磁盘中保存页面的静态副本：当 Cloudflare 边缘节点命中缓存时，本地缓存不会参与，直接返回结果；当 Cloudflare 缓存未命中、请求回源时，本地缓存则能迅速响应，避免 PHP 和数据库被频繁调用。

换句话说，本地缓存和 Cloudflare 缓存可以形成互补：前者保证源站性能，后者提升全局加速效果。因此，对于大多数站点来说，并不建议关闭 “Disk Page Cache”，而是让 SPC 通过 API 保持两层缓存的同步清理，从而获得更高效、也更稳妥的缓存体系。

这种“双层缓存”特别适合以下场景：

• 源站性能有限：比如低配 VPS，如果仅依赖 Cloudflare，一旦遇到缓存未命中，源站可能被压垮，而本地缓存能兜底。
• 访问量较大：高并发时，本地缓存能大幅减少数据库查询压力，提升稳定性。
• 缓存策略灵活性不足：Cloudflare 默认不缓存 HTML，而本地缓存能弥补这一点，再配合 Cloudflare 边缘缓存叠加加速。

当然，本地缓存同样可能缓存到不应缓存的动态页面(如购物车、登录后台），因此可能仍然要通过排除规则来规避误缓存问题。

---

3.2.3 Cloudflare:CDN&Edge Caching

这部分区域用于将插件与 Cloudflare 帐号打通，这是 SPC 与传统本地缓存插件最大的差异点所在。通过这一部分的设置，WordPress 的缓存逻辑能够直接延伸到 Cloudflare 边缘节点，实现全站级别的动态页面加速。

在这里，用户需要配置 Cloudflare 的身份验证信息，可以选择传统的 Global API Key，也可以使用更推荐的 API Token。后者能够针对性地控制权限，安全性更高，也更符合 Cloudflare 的官方最佳实践。一旦完成连接，插件就能自动与 Cloudflare 交互，进行缓存推送与清理，而不需要用户手动去后台操作：

点击下方的按钮”Connect to Cloudflare”之后：

保存域名成功后激活Cloudflare CDN & Cache功能并更新设置：

然后SPC会自动在cloudflare后台创建一条缓存规则：

缓存规则内容如下(太长了显示不完，截个图意思一下)：

SPC生成匹配条件的表达式完整内容如下：

(http.host wildcard "blog.tangwudi.cc*" and not http.cookie contains "comment_" and not http.cookie contains "woocommerce_" and not http.cookie contains "wordpress" and not http.cookie contains "xf_" and not http.cookie contains "edd_" and not http.cookie contains "jetpack" and not http.cookie contains "yith_wcwl_session_" and not http.cookie contains "yith_wrvp_" and not http.cookie contains "wpsc_" and not http.cookie contains "ecwid" and not http.cookie contains "ec_" and not http.cookie contains "bookly" and not http.request.uri contains "ao_noptirocket" and not http.request.uri contains "jetpack=comms" and not http.request.uri contains "kinsta-monitor" and not http.request.uri contains "ao_speedup_cachebuster" and not http.request.uri contains "removed_item" and not http.request.uri contains "/my-account" and not http.request.uri contains "/wc-api" and not http.request.uri contains "/edd-api" and not http.request.uri contains "/wp-json" and not http.request.uri contains "/wp-admin" and not http.request.uri contains "/wp-login" and not http.request.uri.path contains ".xml" and not http.request.uri.path contains ".xsl" and not http.request.uri.path contains "robots.txt")

另外，浏览器TTL我改为了”绕过缓存”，不过和默认的”接受源服务器TTL”感觉差别不大，毕竟主要还是受限于cloudflare边缘缓存的刷新时间：

3.2.4 其它附加优化功能

除了核心的缓存与 Cloudflare 边缘节点联动功能，Super Page Cache 还内置了一些常见的本地优化选项。这些功能并不是插件的独特卖点，但胜在整合在一起，减少了站长额外安装其他小插件的麻烦。

在 Files 方面，插件提供了 Google Fonts 的优化选项，可以将多种字体请求合并为一个文件，甚至直接把 Google Fonts 下载到本地服务器加载，避免外部请求带来的延迟和潜在合规问题：

在 Media 方面，插件支持图片延迟加载（Lazy Load）。站长既可以启用浏览器原生的懒加载机制，也可以切换到插件自带的方案，获得更精细的加载控制。这样能有效降低首屏的带宽消耗，让页面在用户感知上“更快”：

在 Database 方面，插件提供了清理和优化数据库的工具。包括定期清理旧的文章修订版、草稿、垃圾评论、无效的 transient 数据等，还能对数据表进行碎片整理。对于运营时间较长、数据库积累较多冗余数据的站点，这些工具能起到减负和提速的作用：

这些附加功能其实不算重要，只能算是锦上添花，如果你的站点已经在使用像 WP Rocket、LiteSpeed Cache 或 Autoptimize 这样的综合优化插件，就可能和 SPC 存在部分重叠。在这种情况下，可以根据需要选择启用或关闭对应功能，以避免重复优化或潜在冲突。

4 SPC与Cloudflare账户联动的关键

在 2.2 节我提到：“当你在后台发布、更新文章，或者调整站点内容时，SPC 会自动调用 API，通知 Cloudflare 清理或刷新相关页面的缓存。换句话说，缓存“是否能进边缘”的前提，取决于 Cloudflare 自身的缓存规则；而 SPC 的职责，是在内容变化时把该清的清、该刷的刷，让边缘副本与站点内容保持同步”。这句话的真正含义，就是把 “谁来缓存” 与 “谁来管理缓存生命周期” 明确分工。

Cloudflare 的默认策略很克制：边缘只会缓存静态资源（如 CSS、JS、图片），不会默认缓存 HTML。因此，就算 SPC 在本地把页面静态化、也把“联动清理”做得很好，如果没有额外策略，边缘节点仍然会把 HTML 当作动态内容回源，每次看到的 “cf-cache-status” 就会是 DYNAMIC。

要改变这一点，SPC 插件已经内置了解决方案：在 “Cloudflare: CDN & Edge Caching” 选项里启用 Enable Cloudflare CDN & Caching 并点击 Update settings，SPC 会自动调用 Cloudflare API，为你的站点生成一条 Cache Rule(细节详见3.2.3)，这条规则的作用就是：允许 HTML 被缓存，并自动排除掉后台、登录态、接口、购物流程等敏感场景，避免误缓存。换句话说，SPC 不仅负责联动清理，还会替你配置好“Cache Everything”规则，不需要再手动跑去 CF 写一遍。

把它和 APO 对比一下更清楚：APO 等于“让 HTML 默认进边缘缓存 + 和 WordPress 联动”。而 SPC 的组合逻辑是：插件自动创建 Cache Rule，解决“让 HTML 进缓存”；再用 API 精准清理，解决“联动刷新”。机制不同，但体验相对接近；差别在于，SPC 本身不会把页面“推送”到边缘，它只是确保边缘的副本在你改动内容后被及时刷新或删除。

在 Cloudflare 免费订阅账户的场景下(付费订阅有 APO，不需要 SPC～)，想让 SPC 真正发挥作用，关键有三点：

第一，先有资格：确保在 SPC 设置里启用了 Cloudflare CDN & Caching，并同步生成Cloudflare上的缓存规则，这样 HTML 就具备被缓存的资格。

第二，再谈联动：由 SPC 在你发布、更新、删除、评论变更时，调用 Cloudflare API 做定点清理，避免“本地已更新但边缘滞后”的不同步。

第三，保留例外：后台、登录态、购物流程、接口与预览等必须绕过缓存，否则就会误缓存。SPC 自动生成的规则已经涵盖了这些常见排除项，但用户依然可以在 Cloudflare 仪表盘里根据自己需求进一步微调。

落到实操，可以把思路简化成一句话：“让 Cloudflare 负责存，把存什么说清楚；让 SPC 负责管，把何时失效说清楚。” 对免费用户来说，这就意味着两步：在 SPC 插件里启用 Cloudflare CDN & Caching(自动生成 Cache Rule)，其余交给 SPC 的自动清理。Cloudflare 官方的“默认缓存行为”和“Cache Rules”文档明确了这套做法的正当性与边界，配合 SPC 的“按 URL 清理”逻辑，就能稳定复刻接近 APO 的效果。

这里也顺带纠正一个常见误会，默认Cloudflare上未配置”Cache Everything”类的缓存策略时，看到响应标头 cf-cache-status: DYNAMIC 不等于 SPC 失效：

注：为了避免本地缓存功能干扰观测SPC插件和Cloudflare缓存联动结果，在后面的测试中我都关闭了该功能，实际使用的时候并不需要关闭。

它只说明“这次请求的 HTML 没被 Cloudflare 视为可缓存对象”。当 SPC 的自动规则启用后，首次访问通常是 MISS(回源并写入边缘)：

后续就能看到 HIT：

而当你在 WordPress 里更新内容时，SPC 会把相关 URL 的边缘副本清掉，下一次请求又会回源写入，之后继续命中。这才是 “规则 + 联动” 的协作节奏。

最后，把不同路线交代清楚，便于大家判断取舍：如果你使用的是 Pro / Business / Enterprise 套餐，直接在Wordpress里安装cloudflare官方插件并按照流程启用APO即可，Cloudflare 会自动把 HTML 放进边缘缓存，无需额外操作；如果你是 Free 用户，则需要依靠 SPC 插件自动生成的缓存规则，同样能让 HTML 被缓存到边缘节点。两条路径虽然方式不同，但目标一致：让 WordPress 的 HTML 在全球边缘“快起来”，并且在你修改内容时“跟得上”。

---

本章讲述了 SPC 如何配合 Cloudflare 账户（主要是免费订阅账户），实现 HTML 页面缓存的联动机制。需要注意的是，对于没有 APO 或边缘缓存概念基础的读者，即便我将本章内容写得再清晰，也可能难以完全理解 SPC 的真正优势。换句话说，这里的核心本质依赖于对 边缘缓存、HTML 缓存策略与 API 刷新机制 的认知。

对于刚接触 WordPress 或 CDN 缓存原理的用户，可以先将 SPC 理解为一个 “本地缓存插件 + 能帮你在 Cloudflare 自动配置缓存规则，并在内容变动时刷新缓存的工具”。这样就不必担心规则怎么写、缓存何时刷新，核心思想先建立起来，再结合前章知识逐步理解联动机制的全貌。

---

5 SPC实际效果验证

5.1 访问加速验证

从逻辑上讲，本章原本应该安排一节专门测试 SPC”本地缓存”功能对访问速度的加速效果。但在实际操作中，这部分测试并不容易做到“纯粹验证 SPC”，原因在第4章讲述SPC与cloudflare联动机制时已经讲过：

• Cloudflare 默认不会缓存 HTML 页面：即使 SPC 正常工作，你在开发者工具里看到的 cf-cache-status 依然是 DYNAMIC。这并不是 SPC 失效，而是 Cloudflare 自身的策略决定的。
• 要验证加速效果，必须依靠SPC自动添加的缓存规则来实现”Cache Everything”的效果：只有让 Cloudflare 真的缓存 HTML 内容，才能看到明显的 HIT 与 MISS 切换。但这就已经引入了额外的规则配置，测试结果就无法再单纯归功于 SPC。

另外，对于 WordPress 的各种本地缓存插件来说，实现的加速效果(即通过本地生成页面静态副本提升访问速度)其实大同小异(这也是 SPC和cloudflare缓存联动机制显得尤为出色、鹤立鸡群的原因)，所以我觉得也没什么太大的测试必要，本文的重点还是放在联动效果验证上。

5.2 SPC与Cloudflare缓存联动效果验证

以测试URL”https://blog.tangwudi.cc/game/trinitycore1/“为例。

1、先确保”cf-cache-status”为”HIT”：

2、在文章编辑界面新增一段内容：

3、等待几分钟后刷新页面，理论上此时SPC应该已经通知CF清除了缓存中该URL对应的内容，所以此时”cf-cache-status”应该为”MISS”(注意，此时文章内容还没有更新)：

再等一会后又刷新页面，文章添加内容成功，且”cf-cache-status”变为”HIT”：

注：SPC 在文章更新后会自动通过 API 通知 Cloudflare 刷新对应页面缓存，但刷新缓存的速度受 Cloudflare 套餐影响——免费账户通常较慢，而使用 APO 的账户几乎即时生效。此外，访客的网络环境(运营商、区域、网络类型等)和浏览器自身缓存策略也会影响更新显示：即便 Browser Cache-Control 设置为 60 秒或者更短，同一浏览器窗口刷新页面仍可能显示旧内容，因为浏览器优先使用本地缓存。相反，新开的浏览器窗口或无痕模式访问时，浏览器没有缓存历史，会直接从 Cloudflare 边缘节点获取最新 HTML，可能会更快更新。总之，SPC 可以保证内容最终同步，但刷新延迟是正常现象。

---

从这一节的测试结果来看，SPC 的确能够在 文章内容改动后自动调用 API 刷新 Cloudflare 边缘缓存，只是边缘缓存内容生效的时间比较难说。除此之外，它也提供了手动触发更新的功能，例如只清理当前文章的缓存，操作方式如下。

1、在文章编辑界面删除之前添加的内容并点击更新：

然后在WP后台顶部栏找到SPC的Cache图标，点击最下方的”Purge cache for this page only”:


当然，也可以在这里文章列表处实现相同的操作：

---

6 后话

和 APO 相比，SPC 的实际体验总体还算不错。虽然在缓存刷新速度、浏览器缓存处理以及某些动态页面的兼容性上，仍与 APO 存在一定差距，但在目前 WordPress 免费方案中，它已经算是出类拔萃的选择了。特别是乞丐版 APO 已经不被推荐的情况下，SPC 为使用 Cloudflare 免费套餐的个人站长或中小型站提供了一条相对清晰、可控的缓存方案。

从操作体验上看，SPC 的自动刷新功能可以在文章内容更新后通过 API 同步到 Cloudflare 缓存，减少手动清理的麻烦；同时，它提供了手动清除当前页面或整个站点缓存的选项，为站长提供了一层“安全网”。即便有延迟，这种半自动化的机制也比完全依赖本地缓存或频繁登录 Cloudflare 仪表盘清理缓存要便利许多。

相比其他 CDN 或缓存方案，SPC 的独特之处在于，它是少数能够在普通 WordPress 环境下直接联动 Cloudflare 的插件。大部分主流 CDN——无论是 Akamai、Fastly、AWS CloudFront 还是 KeyCDN——虽然提供刷新 API，但通常需要站长自己写脚本或使用第三方工具来实现“文章更新 → 自动刷新缓存”的功能。少数托管型 WordPress 服务会在后台自动管理缓存，但这是服务商专属，无法直接在任意环境中使用。SPC 则以免费开源的形式，让站长在 Cloudflare 免费套餐下，也能享受到自动刷新、手动控制、缓存策略可视化等便利，是目前免费 WordPress 缓存方案中极为罕见且实用的选择。

当然，缓存从来不是为了折腾而折腾，它的目标是让站长少操心，让访客享受顺畅的访问体验。理解底层原理、掌握工具使用方法，再简单的插件也能发挥不简单的价值。SPC 也好，APO 也好，本质上都是在帮助你在有限资源下优化站点性能。掌握了缓存逻辑，就像拿到了一把“钥匙”，能够让你的 WordPress 小站在全球访问体验上更稳定、更高效。

回到文章开头提到的“WordPress 缓存困局”，很多站长曾因动态页面复杂、CDN 配置繁琐而望而却步。通过本文的分析，可以看到即便是免费方案，也存在可行路径：理解缓存层次、合理配置本地与边缘缓存、结合自动与手动清理机制，最终能够在保证内容同步的同时，让访客享受流畅的访问体验。