February 28, 2009
简评 WordPress 缓存插件（续：WP Super Cache 篇）
针对 Aw Guo 提出的问题，我做了个小试验：
1、建立一个干净的 WordPress 站点，设置 Permalink 格式为 /post/%postname%.html
2、安装最新版的 WP Super Cache 并将其激活，设置状态为 ON，并按照说明修改两处 .htaccess
3、通过浏览器访问首页、唯一的单篇日志、About 页面使 WP Super Cache 生成这三个页面的缓存，在 /wp-content/cache/ 目录下可以看到三个以 wp-cache- 起始、以 .html 结尾的 HTML 文件，其中内容分别为完整的页面源代码，注意到末尾均含有 WP Super Cache 字样的注释
4、完整复制整个 /wp-content/cache/ 目录内容到 /wp-content/cache2/
5、禁用 Super Cache 插件，注意到此时 /wp-content/cache/ 目录下所有缓存文件及此目录下的 .htaccess 文件被删除，但 /.htaccess 文件没有变化，其中内容仍然含有 WP Super Cache 的 RewriteRules
6、重命名 /wp-content/cache2/ 目录为 /wp-content/cache/
7、再次通过浏览器访问首页、唯一的单篇日志、About 页面并分别查看其源代码，发现末尾并没有包含 WP Super Cache 字样的注释
结论：
1、WP Super Cache 确实生成了完全静态化的页面缓存（之前我错了）
2、WP Super Cache 并没有通过 /.htaccess 文件中的 RewriteRules 来访问页面对应的缓存，而很可能是通过 WP Super Cache 插件本身的 PHP 代码进行重定向，或者对缓存数据进行读取（有待于进一步验证，WP Super Cache 代码比较多，懒得细看了）
3、Hyper Cache 轻松打败 WP Super Cache 的说法不准确，二者的性能应该处于同一量级，但究竟孰优孰劣，有待于更严谨、更精确的实验数据来证明
4、WP Super Cache 与 Hyper Cache 类似，要起到缓存的作用仍然依赖于 WordPress 插件机制，无法像 cos-html-cache 那样彻底绕过 WordPress
辛苦了，我没有做这个实验，我也不清楚为什么会没有那个注释，但我想，PHP无法阻碍htaccess吧?
@Aw+Guo PHP 是运行于 Apache 之上的一个模块，它的优先级肯定低于 Apache 本身的 .htaccess，现在的问题就在于：WP Super Cache 写在 .htaccess 中的规则并没有包含控制页面请求重定向至缓存的语句；另外，如果在 .htaccess 中定义了将所有页面请求重定向至缓存文件本身，那样我们在访问该页面时应该会发现地址栏中显示的 URL 实际上变成了缓存文件的 URL，所以我推测，WP Super Cache 缓存机制应该和 Hyper Cache 类似，是借助于 PHP 代码读取文件流。
@北极冰仔
cos-html我已经放弃了，因为总是出问题，譬如有时无法评论，譬如post-views无法使用，总会有这样那样的问题。
我现在改用super-cache了。希望将来Hyper-cache升级后，能真正打败super-cache，打造国人wp插件品牌。继续努力，关注ing！
很有实验精神哈。
@Raymond
cos-html-cache 插件适用条件确实有点苛刻，实不相瞒，我曾经也是装了卸，卸了再装，如此反反复复（站内搜索 cos-html-cache 可能会看到），你说的没错，总有这样那样的问题让人不满意，直到后来自己也折腾累，也想通了，放弃了一些花哨的动态功能，重新用上 cos-html-cache 直到现在。
博主似乎没有仔细看super-cache的rewrite语句,它是说在存在cookie的条件下将会重定向到super-cache目录下对应站点的缓存文件.
换言之,位于cache目录下的以wp-cache开头的缓存文件并不是对应rewrite语句的,很明显这些文件是php文件流定向的.所以禁用super cache后不会采用cache目录下的文件.
我用super cache总会遇到各种问题, 主要是我不想把我的缓存文件删掉, 但总是不如意,改了些代码也没有得到我想要的行为.
现在发现还是hyper cache好用些.
cos-html-cache对mu的支持实在是有问题, 光说生成首页html文件这个,对于mu来说会造成混乱.
在这里问问,博主侧边栏最上面的通过 RSS 订阅的下拉框是什么widget?还是插件?可否告知名字?
@海妖的夜 说了这么半天，我和你是同一个意思啊，那些缓存文件肯定不会是通过 RewriteRules 重定向的，只是通过 PHP 读取文件流罢了。（见第 2 条留言）
Hyper Cache 从结构上来说就比 Super Cache 简单得多吧，代码几乎就是 cos-html-cache 的翻版（夸张了点，但真的很像，虽然也有不小的差异），另外你提到 WordPress MU 的问题，这个我没有考虑过，毕竟我这里只是一个 personal blog，也没想到为其他人提供 MU 服务，所以……一句话概括：cos-html-cache 对我来说就是最佳选择。
那个 RSS 订阅下拉框就是最普通的 HTML 代码，不需要任何插件、Widget。
怎么我设置super-cache后，留言不能立即显示，怎么改配置呢？
@atp 貌似 Super Cache 会自动处理这种情况的吧？刷新下浏览器应该可以看到吧。
4、WP Super Cache 与 Hyper Cache 类似，要起到缓存的作用仍然依赖于 WordPress 插件机制，无法像 cos-html-cache 那样彻底绕过 WordPress
意思是說: cos-html-cache優於WP Super Cache 与 Hyper Cache嗎???
@Zack 在这个方面 cos-html-cache 有绝对优势。
用这个插件好像在手机上访问有些问题，弄了不到半小时就被我反安装了
緩存文件的確是透過rewrite去訪問的 並不需要經過php
我來解釋一下 super-cache的rewrite條件吧
RewriteCond %{REQUEST_METHOD} !=POST #如果不是POST
RewriteCond %{QUERY_STRING} !.*=.* #如果不是GET
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ #如果cookie裡面 沒有wordpress等字樣
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f #如果該文件緩存檔案存在
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L] #導引到該緩存輸出之
除非該文件不存在 這條件才會往下走 經過php才有機會被執行
呃，我也在选择中，看哪种好
不错的插件，效果如何
看着有些迷糊 暂时不做实验了
我的理解是WP Cache生成的半静态页面的页面源码的最后是像下面这样的注释
如果是WP Super Cache模式生成的完全静态页面最后会多
在Cache目录下能找到分别对应的html文件。
我不明白的是在有RewriteRule的情况下，为什么有时还是没有调用完全静态页面
好东西啊。。。