内容页生成纯静态缓存

其实没有多大必要生成真静态，更好的策略可能应该是伪静态，或者真伪相结合，这样灵活性非常高，但是我的空间不支持URL重写所以要搞缓存只能用真静态了。

生成静态的优势大抵如下：
1.SEO优化

这个该是公认的，至于为什么搜索引擎喜欢更静态页面，可能是因为静态页面相对稳定，动态页面常常因为系统改版或程序错误而失效，还可能静态的容易解析吧？

2.主机负载大大提高

前提是缓存系统策略得当，缓存以牺牲“写”能力能提高“读”能力的，一般的WEB应用中读的频率远高于写，所以大都能得益于缓存系统，但若因此造成“写”的负担大大增加，可能得不偿失。

3.浏览速度提升

有得必有失，同样的静态缓存也有很大的缺陷

1.管理复杂

为了兼顾数据驱动程序的功能与静态页面的优势，要使用各种更新缓存策略，势必增大的开发、调试复杂度。

2.磁盘空间浪费，更新大站时速度慢

以空间换时间，一般来说都值得，大多情况下，在硬盘空间消耗完毕前，CPU,数据库和带宽资源早就挂了。

当然，我设计缓存系统更主要是为了练手，提高对自己的要求有益于进步。

缓存有几个不同的层次（级别）：查询缓存、块级缓存（如侧栏的一个列表），更大的块缓存（整个侧栏），整页缓存。

以前做过块级缓存，但这次要做真静态，我决定用整页缓存，不过使用的过程中，发现首页和各栏目首页做缓存的话更新缓存代价太高，系统也很难控制因为放弃了，只对内容页做缓存吧。写了两天又发觉做整页缓存的代码还是高，例如新发布日志或修改时，为了更新侧栏（因为侧栏可能要发生变化）只能把所有的日志缓存全删了！

为了克服这个问题，内容页只缓存了正文部分，不缓存侧栏，而侧栏是用AJAX自动载入的（侧栏也有缓存），这样数据发生变化时，只需要把侧栏缓存删了即可，以前的日志缓存不受影响。日志缓存只有在评论或修改时才重建。

总结一下，本次我采用把一页分为主体和侧栏两个部分分别缓存，当浏览器载入主体之后，触发AJAX向后台取侧栏缓存，纯静态页中，利用ajax保持了动态功能。这样在“读”与“写”、速度与功能上取得了较好的平衡。

至于具体怎么生成缓存呢？其实很简单，一个file_put_contents函数而己，以日志模块为例