max-age
When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate
its own cache entry, and the client has supplied its own validator in the request, the
supplied validator might differ from the validator currently stored with the cache entry.
In this case, the cache MAY use either validator in making its own request without
affecting semantic transparency.
However, the choice of validator might affect performance. The best approach is for the
intermediate cache to use its own validator when making its request. If the server replies
with 304 (Not Modified), then the cache can return its now validated copy to the client
with a 200 (OK) response. If the server replies with a new entity and cache validator,
however, the intermediate cache can compare the returned validator with the one provided in
the client's request, using the strong comparison function. If the client's validator is
equal to the origin server's, then the intermediate cache simply returns 304 (Not
Modified). Otherwise, it returns the new entity with a 200 (OK) response.
If a request includes the no-cache directive, it SHOULD NOT include min-fresh,
max-stale, or max-age.
9 回答
max-age=0
这相当于单击“刷新”，这意味着，除非我已经拥有最新的副本，否则请给我最新的副本 .
no-cache
单击“刷新”时按住Shift键，这意味着，无论如何都只需重做所有内容 .
现在老问题，但是如果有其他人像我一样通过搜索遇到这个问题，那么看起来IE9将使用它来配置使用后退和前进按钮时的资源行为 . 当使用max-age = 0时，浏览器将在后退/前进按下时查看资源时使用最后一个版本 . 如果使用no-cache，则将重新获取资源 .
关于IE9缓存的更多细节可以在msdn caching blog post上看到 .
不同之处在于no-cache（Firefox上没有存储）会阻止任何类型的缓存 . 这对于防止将具有安全内容的页面写入磁盘以及即使使用后退按钮重新访问它们也应始终更新的页面非常有用 .
max-age = 0表示缓存条目已过时且需要重新验证，但不会阻止缓存 . 通常，浏览器仅在每个浏览器会话中验证一次资源，因此在新会话中访问该站点之前，内容可能不会更新 .
通常，浏览器不会删除过期的缓存条目，除非它们在浏览器缓存已满时回收更新内容的空间 . 使用no-store，no-cache允许显式删除缓存条目 .
礼貌：http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
不接受这个作为答案 - 我将不得不阅读它以了解它的真实用法:)
我有同样的问题，并在我的搜索中找到了一些信息（你的问题出现了其中一个结果） . 这就是我的决心......
Cache-ControlHeaders 有两个方面 . 一方是Web服务器可以发送的地方（又名"origin server"） . 另一边是浏览器可以发送的地方（又名"user agent"） .由源服务器发送时
我相信
max-age=0只是告诉缓存（和用户代理）响应从一开始就陈旧，所以他们在使用缓存副本之前重新验证响应（例如，使用If-Not-Modified标头），而no-cache告诉他们之前 MUST 重新验证使用缓存副本 . 从14.9.1 What is Cacheable：换句话说，缓存有时可能会选择使用陈旧的响应（虽然我认为他们必须添加
Warning标头），但no-cache表示他们想要在页面中生成棒球统计数据时 SHOULD -revalidate行为，但是你当您生成对电子商务购买的响应时，我希望 MUST -revalidate行为 .虽然当你说
no-cache不应该阻止存储时你的评论是正确的，但是当使用no-cache时它可能实际上是另一个区别 . 我遇到了一个页面，Cache Control Directives Demystified，它说（我不能保证它的正确性）：顺便说一句，在我看来，
Cache-Control: max-age=0, must-revalidate基本上应该与Cache-Control: no-cache相同 . 所以也许这是一种获得no-cache的 MUST -revalidate行为的方法，同时避免no-cache的明显迁移与no-store做同样的事情（即没有任何缓存）？由用户代理发送时
我相信shahkalpesh's answer适用于用户代理方 . 你也可以看看13.2.6 Disambiguating Multiple Responses .
如果用户代理使用
Cache-Control: max-age=0（也称为"end-to-end revalidation"）发送请求，则沿途的每个缓存将重新验证其缓存条目（例如，使用If-Not-Modified标头）一直到源服务器 . 如果回复是304（未修改），则可以使用高速缓存的实体 .另一方面，发送带有
Cache-Control: no-cache（aka . "end-to-end reload"）的请求不会重新验证，并且服务器 MUST NOT 在响应时使用缓存副本 .顺便说一下，值得注意的是，有些移动设备，特别是iPhone / iPad等Apple产品完全忽略了无缓存，无存储，Expires：0等 Headers ，或者其他任何你可能试图强制它们不再重复使用的 Headers 表单页面 .
这让我们头疼不已，因为我们试图让用户的iPad问题说，留下在他们通过表单进程到达的页面上睡着了，比如说第2步，然后设备完全忽略了存储/缓存指令，据我所知，只需从页面中获取页面的虚拟快照最后一个状态，也就是说，忽略它被明确告知的内容，而且，不仅仅是这样，采取一个不应该存储的页面，并存储它而不再实际检查它，这会导致各种奇怪的Session问题，等等 .
我只是添加了这个，以防有人出现，无法弄清楚为什么他们会遇到会话错误特别是iphone和ipads，这似乎是这个领域最糟糕的违规者 .
我已经针对这个问题进行了相当广泛的调试器测试，这是我的结论，设备完全忽略了这些指令 .
即使在常规使用中，我发现一些手机也完全无法检查新版本，例如，Expires：0然后检查最后修改日期以确定是否应该获得新版本 .
它根本不会发生，所以我被迫做的是将查询字符串添加到我需要强制更新的css / js文件中，这会欺骗愚蠢的移动设备，使其认为它是一个它没有的文件，例如：my .css？v = 1，然后v = 2进行css / js更新 . 这很有用 .
顺便说一句，用户浏览器，如果保留默认值，截至2016年，因为我不断发现（我们对我们的网站进行了大量更改和更新）也无法检查此类文件的最后修改日期，但查询字符串方法修复了这个问题 . 这是我注意到的客户和办公室人员，他们倾向于在浏览器上使用基本的普通用户默认值，并且没有意识到css / js等缓存问题，几乎总是无法获得新的css / js，这意味着他们的浏览器的默认值（主要是MSIE / Firefox）没有做他们被告知要做的事情，他们忽略更改并忽略上次修改日期并且不验证，即使明确设置了Expires：0 .
这是一个很好的技术信息很好的线程，但同样重要的是要注意这些东西在特别是移动设备中的支持有多糟糕 . 每隔几个月我就必须添加更多层保护，以防止他们无法遵循他们收到的 Headers 命令，或者正确地插入这些命令 .
在我最近使用IE8和Firefox 3.5进行的测试中，似乎两者都符合RFC . 但是，它们的"friendliness"与原始服务器不同 . IE8使用与
max-age=0,must-revalidate相同的语义处理no-cache响应 . 但是，Firefox 3.5似乎将no-cache视为等同于no-store，这会影响性能和带宽使用 .默认情况下，Squid Cache似乎永远不会存储任何带有
no-cache标头的内容，就像Firefox一样 .我的建议是为每个请求检查新鲜度的非敏感资源设置
public,max-age=0，但仍然允许缓存的性能和带宽优势 . 对于具有相同考虑因素的每用户项目，请使用private,max-age=0.我会完全避免使用
no-cache，因为它似乎被一些浏览器和流行的缓存所混淆，功能相当于no-store.此外，不要模仿Akamai和Limelight . 虽然他们基本上运行大量缓存阵列作为他们的主要业务，并且应该是专家，但他们实际上有一种既得利益，可以从他们的网络下载更多的数据 . 谷歌也许不是一个很好的选择 . 他们似乎随机使用
max-age=0或no-cache，具体取决于资源 .这是一个小决策树，我希望能澄清其中的差异 .
我不是一个缓存专家，但Mark Nottingham是 . 这是他的caching docs . 他在参考文献部分也有很好的链接 .
基于我对这些文档的阅读，看起来
max-age=0可能允许缓存向"same time"中的请求发送缓存响应，其中"same time"意味着足够接近它们同时看起来与缓存，但no-cache不会 .