iPhone 会在本地缓存页面，而您必须清理缓存才能获取新内容，这对我来说听起来很奇怪。
事实上，必须有一些 HTTP 缓存头告诉 iPhone 浏览器这样做。
浏览器是 iOS 上的 Safari，Android 上的 Opera，或 Windows 上的 Firefox，这无关紧要，因为所有现代浏览器都“应该”符合HTTP 1.1 RFC，甚至是移动浏览器。
当然，它们在节省带宽、手机电池和手机 CPU 周期方面可能存在一些差异，但它们绝对应该允许用户从网站获取新鲜内容。所以我同意你的看法，清理访问过的页面不是正确的做事方式。
我肯定认为某处有问题。尝试通过计算机浏览器调用 API，并通过 firebug 或 chrome 的原生调试工具检查请求，检查服务器响应标头，并查看行为是否相同。
通常我混合使用 max-age 和 if-modified-since 缓存验证器。
我将一些图像的 max-age 设置为较高的值（在我的情况下为 365 天，很可能不适合您），对于其他一些图像设置为一周，以及一天的 css 和 javascript。
此外，我使用 if-modified-since，因此我在内容的新鲜度、服务器负载和带宽使用之间取得了很好的平衡。 ETAG 与 if-modified-since 基本相同，不同之处在于可以将其设置为弱缓存验证器，如果服务器的时钟不可靠，它确实很有用。 （有关更多信息和对文档的引用，请参阅下面的扩展答案）
要启用缓存，IIS7 使用输出缓存 IIS 模块让您非常轻松。 Here is 一个关于它的好文档，关于如何启用它，以及内核和用户模式缓存之间的区别。
除非您需要做一些非常特别的事情，否则我认为您不需要为它创建代码，而 IIS 会处理所有事情。如果不是这种情况，那么这里是another good guide，它将帮助您。
如果您真的想要一个快速的网站，那么我建议您启用压缩，并在应用程序和数据库之间添加一个缓存层。因此，您不会对每个请求都执行对数据库的查询。
这里是some more good performance guidelines，适用于任何网络开发人员。
扩展答案（甚至可能过于扩展:)）
通过 HTTP 1.1 在客户端缓存内容的方式有多种。
最常见的，或者至少是我用得最多的是：
- 最大年龄
- 最后修改
- etag
1) max-age 标头是从服务器发送的，位于 HTTP 响应标头上，主要是告诉客户端的浏览器将内容存储在其缓存中，时间以秒为单位。
例如，假设服务器返回 max-age=60 以响应 logo.jpg 的 GET 客户端 http 请求。然后客户端的浏览器存储 logo.jpg 并在接下来的 60 秒内从自己的缓存中提供图像。
换句话说，在接下来的 60 秒内不会有针对此特定图像的 HTTP 请求。
因此，使用 max-age 时，内容将缓存在客户端，并且在 max-age 标头中指定的秒数内不会被服务器请求或重新验证。
然而，通常可以通过在 windows 浏览器上按 CTRL-F5 和在 mac 浏览器上按 CMD-R 来强制重新验证/刷新。在移动设备上，该功能通常位于浏览器菜单上，称为刷新。这是 RFC 的 appropriate section。
优点
- 没有 TCP 连接和对服务器的 HTTP 请求，因此服务器端的工作量更少（如果您的应用有很多用户，这真的很有用）
- 内容在本地加载，直接从浏览器缓存中加载，因此内容加载没有延迟
- 不使用带宽（如果数据中心向您收取入站和出站带宽的费用，这很有用）
缺点
- 如果您在服务器上有新鲜内容，那么客户端将不会知道，直到客户端的缓存过期或用户强制刷新浏览器。
2) 最后修改的服务器端 http 响应标头与客户端 http 请求标头 if-modified-since 一起，是加快网站速度和节省一些钱的另一个好机制。它基本上以这种方式工作。
浏览器首次通过 GET 请求向服务器请求内容。
服务器以 200 响应并返回内容以及最后修改的标头。
last-modified 标头的值就是上次修改内容的实际日期和时间。 （由于时区，日期时间必须是 UTC）
此时，来自客户端的对相同内容的所有以下 HTTP 请求将有一个名为：if-modified-since 的附加标头，其中包含从服务器接收到的日期和时间作为值。
服务器在收到以下请求时将检查 if-modified-since 标头值，并将其与内容的最后修改日期进行比较。
如果数据相同，因此内容没有改变，服务器会响应304，基本上没有内容。 （最重要的部分！）
然后浏览器知道它必须保持缓存中的内容静止并从中加载它，因为它在服务器端没有改变。
该过程将一直持续到服务器上的内容发生更改，因此服务器将提供新的最后修改日期和新鲜内容。
可以看到，这样可以节省很多带宽，尤其是在图片，或者 JS 或者 css 的情况下，不会放弃内容的新鲜度。 Section 14.25 of the spec 比我解释得更好。 :)
优点
- 整个过程涉及的带宽较少，因为如果内容没有改变，服务器只响应304。
- 从客户端重新验证内容，因此客户端将始终拥有最新的最新数据
缺点
- 服务器必须处理 TCP 连接和 HTTP 请求，并检查客户端请求的文件/内容的最后修改日期和时间。
3) ETAG 和 if-modified-since 是一个类似的过程，不同的是，header 的值通常是服务器端内容的哈希值，而客户端在 http 请求上发送一个 header，称为：如果不匹配。
利弊同第2点。
您现在可能想知道第 2 点和第 3 点之间的主要区别是什么。
第 2 点的问题实际上是服务器时钟。事实上，如果有时钟问题，从服务器返回上次修改日期可能会出现问题
这个主题比较深，因为最好的做法是发送一个弱验证器和一个强验证器。请参阅section 13.3.4 了解更多信息。