本文约 3,575 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：免费的、古老的，但至今仍在大量站点上跑着
WP Super Cache 是 Automattic（WordPress.com 母公司）出品的免费缓存插件，历史比 WP Rocket 还久。它不花哨，只做一件事：把页面生成静态 HTML 文件存到 wp-content/cache/supercache/，然后让 Web 服务器直接返回这些文件。
它的关键设置只有一个：简单模式（Simple）还是专家模式（Expert）。这个选择决定了请求是否要启动 PHP。很多站点装完一直停在简单模式（插件默认），页面确实快了一些，但 TTFB 还是在 200–400ms 徘徊；切到专家模式后能降到 40–80ms。差别就在那一行 rewrite 规则上。
原理分析：两条执行路径的差别
| 项目 | 简单模式（Simple / PHP 模式） | 专家模式（Expert / mod_rewrite 模式） |
|---|---|---|
| 命中时是否启动 PHP | 是（先加载 WordPress，再由 PHP 读静态文件） | 否（Web 服务器直接返回静态文件） |
| 配置方式 | 无需改服务器配置 | 需要 .htaccess（Apache）或手工写 Nginx 规则 |
| 兼容性 | 最高，任何环境都能跑 | 依赖服务器模块与规则正确 |
| 典型 TTFB | 150–400ms | 30–80ms |
| 风险 | 低 | 规则写错会导致整站 500 或缓存串号 |
差别可以这么理解：简单模式是”用 PHP 读一个现成的 HTML 文件”，专家模式是”PHP 根本不知道有这次请求”。前者省掉了数据库查询和主题渲染，但仍要启动 PHP-FPM、加载 WordPress 的一部分；后者连这步也省了。
专家模式的规则依赖一个约定：缓存文件路径是 wp-content/cache/supercache/{HTTP_HOST}/{REQUEST_URI}/index.html。Web 服务器先尝试这个文件，存在就直接返回，不存在才走 index.php。另外插件还会生成 .meta 文件记录缓存过期时间，以及一个全局的 WPLOCKDOWN 机制。
还有几个关键常量，写在 wp-config.php 里：
define( 'WP_CACHE', true ); // 总开关，两种模式都需要
define( 'WPSC_DISABLE_COMPRESSION', true ); // 关闭 gzip 压缩，交给服务器处理
define( 'WPLOCKDOWN', true ); // 锁定：已知用户一律不读缓存，直接动态生成
WPLOCKDOWN 是个容易被忽略但很有用的开关：开启后，插件只给”完全匿名的访客”返回缓存，任何带登录 Cookie 的请求都不走缓存路径。这能规避绝大多数缓存串号问题。
保姆级实操
第一步：安装并确认 WP_CACHE
grep -n "WP_CACHE" wp-config.php || \
wp config set WP_CACHE true --raw --type=constant
第二步：基础设置
后台 设置 → WP Super Cache → 高级：
- 勾选”缓存命中后直接提供静态文件”；
- 勾选”压缩页面”（或关掉交给服务器 gzip）；
- 勾选”当有新文章或评论时清理缓存”；
- Cache Timeout：默认
3600秒； - Scheduler：设为 “Clock: 每天一次” 或 “Twice Daily”，用于垃圾回收。
第三步：选择模式
同一页的 Delivery Method 区域：
- Simple：直接保存即可，无需改服务器；
- Expert：插件会尝试写入
.htaccess（Apache）。Nginx 需要手动配置。
第四步：Nginx 下的专家模式规则
插件不会自动写 Nginx 规则，需要手工加入站点配置：
set $supercache_file '';
set $cache_uri $request_uri;
# 只缓存 GET 请求
if ($request_method != GET) { set $cache_uri 'null cache'; }
# 带查询参数不缓存
if ($query_string != "") { set $cache_uri 'null cache'; }
# 登录用户、评论者不缓存
if ($http_cookie ~* "comment_author|wordpress_logged_in|wp-postpass_") {
set $cache_uri 'null cache';
}
if ($cache_uri != 'null cache') {
set $supercache_file "/wp-content/cache/supercache/$http_host/${cache_uri}index.html";
}
location / {
try_files $supercache_file $uri $uri/ /index.php?$args;
}
尾部斜杠的处理很关键：如果站点的固定链接带尾斜杠，路径是 {uri}/index.html；不带尾斜杠则是 {uri}/index.html 也会由插件生成，但 ${cache_uri}index.html 的拼接要匹配。配置后用命令验证：
nginx -t && systemctl reload nginx
# 找一个已缓存的路径确认文件存在
ls wp-content/cache/supercache/mimangfei.com/ | head
第五步：验证命中
curl -sI https://mimangfei.com/ | grep -iE 'cache-control|x-wp-super|x-nocache'
# 第二次请求起应该看到明显更快的 TTFB，且响应头里不再有 PHP 生成的动态标记
for i in 1 2 3; do curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mimangfei.com/; done
第六步：管理缓存目录
# 看看缓存占用
du -sh wp-content/cache/
# 手工清理（后台也有 Delete Cache 按钮）
rm -rf wp-content/cache/supercache/*
# 手工触发垃圾回收后确认目录被清理
常见踩坑
- 切到 Expert 后整站 500。Nginx 规则里变量拼接错误或目录不可读。先在测试环境验证规则。
- 规则没覆盖带尾斜杠的路径。首页能命中，文章页不命中。
- 案例：一个站点切换专家模式后，几位移动端用户反馈看到别人的登录状态。原因是 Nginx 规则里漏了
wordpress_logged_in的 Cookie 判断，而 WP Super Cache 的移动端缓存又开启着，导致带登录 Cookie 的请求读到了别人生成的缓存页。修复是在规则里补上 Cookie 排除，并开启WPLOCKDOWN，彻底杜绝已知用户读缓存。 - 缓存目录无限增长。没配垃圾回收，
wp-content/cache/几个月涨到几十 GB。 - 改了主题但缓存没清。前台还是旧样式，需要手动清空缓存目录。
- 和 Opcode 缓存叠加导致更新延迟。PHP OPcache 里还是旧代码，需要一起清。
- 卸载后
advanced-cache.php残留。和 W3TC 一样，卸载后要手工删除wp-content/advanced-cache.php并确保WP_CACHE被移除。
总结
选择标准很简单：能用专家模式就用专家模式，收益是数量级的（TTFB 从数百毫秒降到几十毫秒），代价只是多写几行服务器规则；只有在无法修改服务器配置的环境（部分虚拟主机）才退回简单模式。无论哪种模式，两件事必须做对：wp-config.php 里的 WP_CACHE 常量，以及规则里对登录 Cookie 的排除。前者决定缓存是否生效，后者决定会不会出现缓存串号——后者一旦出错，后果远比慢一点严重。
想要更省心的付费方案可以看 WP Rocket 配置全解析；服务器层面的优化另见 Nginx 下 WordPress 缓存规则配置。
