来自RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

no - cache 如果no-cache指令没有指定字段名，则缓存 一定不要使用响应来满足后续的请求没有 与原始服务器的重新验证成功。这允许一个原点 服务器来防止缓存，即使缓存已配置为 向客户端请求返回过时的响应。

所以它指导代理人重新验证所有的反应。

相比之下

must-revalidate 当必须重新验证指令出现在收到的响应中 通过缓存，该缓存绝对不能使用该条目后，它变得陈旧 对后续请求作出响应，而不首先对其进行重新验证 源服务器

所以它会引导代理重新验证过时的响应。

特别是关于无缓存，这是用户代理实际上，经验对待这个指令吗?

如果必须重新验证和max-age，那么无缓存还有什么意义呢?

请看下面的评论:

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

no-cache Though this directive sounds like it is instructing the browser not to cache the page, there’s a subtle difference. The “no-cache” directive, according to the RFC, tells the browser that it should revalidate with the server before serving the page from the cache. Revalidation is a neat technique that lets the application conserve band-width. If the page the browser has cached has not changed, the server just signals that to the browser and the page is displayed from the cache. Hence, the browser (in theory, at least), stores the page in its cache, but displays it only after revalidating with the server. In practice, IE and Firefox have started treating the no-cache directive as if it instructs the browser not to even cache the page. We started observing this behavior about a year ago. We suspect that this change was prompted by the widespread (and incorrect) use of this directive to prevent caching.

有人有更正式的消息吗?

更新

当且仅当对表示的请求验证失败可能导致不正确的操作时，服务器才应该使用must-revalidate指令，例如未静默执行的金融事务。

直到现在，我才把这件事放在心上。RFC说不要轻易使用“必须重新验证”。问题是，对于web服务，你必须采取消极的态度，并为你未知的客户端应用程序做最坏的打算。任何陈旧的资源都有可能导致问题。

我刚刚考虑的另一件事是，没有Last-Modified或ETags，浏览器只能再次获取整个资源。然而，对于ETags，我观察到Chrome至少似乎对每个请求都重新验证。这使得这两个指令都没有意义，或者至少命名很糟糕，因为它们不能正确地重新验证，除非请求还包括其他会导致“总是重新验证”的头文件。

我想把最后一点讲清楚。通过设置必须重新验证，但不包括ETag或Last-Modified，代理只能再次获得内容，因为它没有什么可以发送到服务器进行比较。

然而，我的经验测试表明，当响应中包含ETag或修改的报头数据时，无论是否存在必须重新验证的报头，代理总是重新验证。

因此，必须重新验证的重点是在它失效时强制“绕过缓存”，这只会发生在你设置了生命周期/年龄时，因此，如果必须重新验证设置在一个没有年龄或其他报头的响应上，它实际上相当于没有缓存，因为响应将被认为立即失效。

所以我终于要给Gili的答案打分了!