从RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
无缓存
如果no-cache指令未指定字段名，则在未经原始服务器成功重新验证的情况下，缓存不得使用响应来满足后续请求。这样，即使已配置为将陈旧响应返回给客户端请求的缓存，原始服务器也可以防止缓存。
因此，它指示代理重新验证所有响应。
比较这个
必须重新验证
当在缓存接收到的响应中存在must-revalidate指令时，该缓存在过期之前将不能使用该条目来响应后续请求，而不必先通过原始服务器对其进行验证，则该缓存不得使用该条目
因此，它指示代理重新验证过时的响应。
特别是关于no-cache，这是用户代理实际，凭经验对待该指令的方式吗？
什么是点no-cache，如果有must-revalidate和max-age？
看到这个评论：
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
无缓存
尽管此指令听起来像是在指示浏览器不要缓存页面，但还是有细微的差别。根据RFC，“ no-cache”指令告诉浏览器在从缓存中提供页面之前，应先与服务器进行验证。重新验证是一种精巧的技术，可让应用程序节省带宽。如果浏览器已缓存的页面未更改，则服务器仅向浏览器发出信号，并从缓存中显示该页面。因此，浏览器（至少在理论上至少）将页面存储在其缓存中，但仅在与服务器重新验证后才显示页面。实际上，IE和Firefox已经开始对待no-cache指令，就像它指示浏览器甚至不缓存页面一样。大约一年前，我们开始观察这种行为。
有人在这方面有更多官方的吗？
更新资料
服务器仅当且仅当未能验证表示中的请求可能导致错误操作（例如静默未执行的金融交易）时，才应使用must-revalidate指令。
到现在为止，我从来没有想过这件事。RFC表示不要轻易使用必须重新验证。问题是，对于Web服务，您必须持否定态度，并为未知的客户端应用程序假设最糟糕的情况。任何陈旧的资源都有可能引起问题。
我刚刚考虑过的其他东西，如果没有Last-Modified或ETag，浏览器只能再次获取整个资源。但是，使用ETags，我观察到Chrome似乎至少在每次请求时都会重新验证。这使得这两个指令毫无意义，或者至少命名不当，因为它们不能正确地重新验证，除非请求还包含其他标头，这些标头随后仍然导致“始终重新验证”。
我只想使最后一点更清楚。仅设置must-revalidate但不包含ETag或Last-Modified，代理就只能再次获取内容，因为它没有什么可发送到服务器进行比较。
但是，我的经验测试表明，当响应中包含ETag或修改后的标头数据时，无论must-revalidate标头是否存在，代理始终会重新进行验证。
所以点must-revalidate是强制“旁路缓存”时，它会过时，如果当您设置了一生/年龄这只能发生，从而must-revalidate设置上，没有年龄或其他头的响应，它实际上就变成等同于no-cache自响应将立即被视为过期。
-因此，我将最终标记Gili的答案！