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