有了页面缓存，Rails 就可以不再介入。在某种程度上，这是件好事，因为您的确可以获得优秀的性能。Rails 只需创建 HTML 页面，将其放入目录，之后，就可以置之于脑后。从那时起，就由应用服务器管理这些页面，且页面进入应用服务器无需任何循环。从性能的角度而言，页面缓存真是天赐之福。
我也钟爱页面缓存，Rails 使之简单利落。只需使用一行代码就可以启用缓存。如果再加入一些代码，就能通过简单地删除文件操作或使用 Rails 较高层的 API 终止缓存。这里存在一个问题。并不是每个网站都能使用页面缓存。如果页面上的数据会根据访问它的用户而改变，那么就不能进行页面缓存。而且，如果很难判断页面何时到期终止，就会发现页面缓存的要求太过苛刻。
比如，几乎在每个页面上，ChangingThePresent.org（参阅 侧栏）都有某些用户数据是根据当前登录的用户而变化的。图 1 显示了我们最新主页的一部分。（我们一直在努力完善它，所以它有可能会改变。）这个页面呈现出的问题相对简单。如果能判断用户是否已经登录，就可以用 Flash、JavaScript、DHTML 或任何其他基于浏览器的代码动态定制视图。您会发现已登录的用户可以登出系统或查看其配置文件，而已登出的用户则可以注册或再次登录。
图 1. ChangingThePresent.org 上的登录和登出视图
图 2 显示了稍微有些高级的用户数据视图，我们的站点就使用了这个视图。图 2 中的两个视图有极大的不同。为了处理页面缓存，我必须先解决所有的差异。对于每个已登录的用户，我都必须替换掉页面的登出内容，使之显示登录用户的登录 ID 和用户图片。缓存这些内容会带来另一层面的挑战，因为每个用户的数据都不尽相同。
图 2. 两个截然不同的视图
这种情况并非 ChangingThePresent.org 所独有。如果需要个性化用户体验，那么不可修改的 Rails 页面缓存的使用就会受到限制。但如果定制不多，那么实际上还是能很容易地缓存这些页面的。
解决这些问题的方法很多。我更倾向于使用如下这些技巧：
在 Rails 框架的约束之内，取消页面缓存并使用段缓存替代它。 先加载页面的大部分，然后使用 JavaScript 和 Ajax 加载该页面较小的动态部分。服务器端代码可以检测用户是否登录，然后用 Ajax 呈现合适的部分。 将某些用户状态（比如用户是否已登录）存储在客户端的 cookie 中。然后，根据 cookie 的内容，使用 JavaScript 动态更改页面的外观。新闻热点
疑难解答
