标题Cache-Control: max-age=0表示内容被认为是陈旧的（并且必须立即重新获取），这实际上与Cache-Control: no-cache相同。
答案 0 :(得分：548)
我有同样的问题，并在我的搜索中找到了一些信息（您的问题出现在其中一个结果中）。这就是我的决定...
Cache-Control标题有两个方面。一方是Web服务器（也就是“原始服务器”）可以发送的地方。另一边是浏览器可以发送的地方（也就是“用户代理”）。
我相信max-age=0只是告诉缓存（和用户代理）响应从一开始就陈旧，所以他们应该重新验证响应（例如{{1}在使用缓存副本之前，If-Not-Modified告诉他们在使用缓存副本之前必须重新验证。来自14.9.1 What is Cacheable：
否缓存
...缓存不得使用响应 满足后续要求 没有成功重新验证 原始服务器。这允许一个 原始服务器甚至可以防止缓存 通过已配置为的缓存 返回对客户的陈旧回复 请求。
换句话说，缓存有时可能会选择使用陈旧的响应（虽然我认为他们必须添加no-cache标题），但Warning说他们不允许使用过时无论如何都要回应。在页面中生成棒球统计数据时，您可能需要应该 - 重新生成行为，但是当您生成响应时，您需要必须 - 重新生成行为购买电子商务。
虽然当您说no-cache不应该阻止存储时，您的评论是正确的，但使用no-cache时可能实际上是另一个区别。我遇到了一个页面Cache Control Directives Demystified，它说（我不能保证其正确性）：
在实践中，IE和Firefox都有 开始治疗无缓存 指令好像它指示了 浏览器甚至不缓存页面。 我们开始观察这种行为 大约一年前。我们怀疑 这种变化是由 广泛（和不正确）使用此 防止缓存的指令。
...
请注意，最近，“缓存控制： no-cache“也开始表现了 喜欢“禁止商店”指令。
另外，在我看来，no-cache基本上与Cache-Control: max-age=0, must-revalidate的意思相同。所以也许这是获得Cache-Control: no-cache的必须 - 重新执行行为的方法，同时避免no-cache明显迁移到与no-cache做同样的事情（即。没有任何缓存）？
我相信shahkalpesh's answer适用于用户代理方。您还可以查看13.2.6 Disambiguating Multiple Responses。
如果用户代理发送带no-store的请求（又称“端到端重新验证”），那么沿途的每个缓存都将重新验证其缓存条目（例如，使用Cache-Control: max-age=0标题）一直到原始服务器。如果回复是304（未修改），则可以使用缓存的实体。
另一方面，发送If-Not-Modified请求（又称“端到端重新加载”）不会重新生效，服务器绝不能使用缓存副本响应。
答案 1 :(得分：49)
<强>最大年龄= 0
这相当于点击刷新，这意味着，除非我已经拥有最新的副本，否则请给我最新的副本。
无缓存
这是在点击刷新时按住 Shift ，这意味着，无论如何都只需重做所有内容。
答案 2 :(得分：33)
现在有一个老问题，但是如果有其他人像我一样通过搜索遇到这个问题，那么看起来IE9将使用它来配置使用后退和前进按钮时资源的行为。当使用 max-age = 0 时，浏览器将在后退/前进按下时查看资源时使用上一版本。如果使用 no-cache ，则将重新获取资源。
有关IE9缓存的更多详细信息，请参阅此msdn caching blog post。
答案 3 :(得分：26)
在我最近使用IE8和Firefox 3.5进行的测试中，似乎两者都符合RFC标准。但是，它们与原始服务器的“友好性”不同。 IE8使用与no-cache相同的语义处理max-age=0,must-revalidate响应。但是，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，具体取决于资源。
答案 4 :(得分：19)
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.
礼貌：http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
不要接受这个作为答案 - 我必须阅读它才能理解它的真实用法：）
答案 5 :(得分：12)
我不是一名缓存专家，但Mark Nottingham是。这是他的caching docs。他在参考文献部分也有很好的链接。
根据我对这些文档的阅读，看起来max-age=0可以允许缓存向“同一时间”进来的请求发送缓存响应，其中“同一时间”意味着足够接近他们看起来同时缓存，但no-cache不会。
答案 6 :(得分：11)
顺便说一下，值得注意的是，某些移动设备，尤其是iPhone / iPad等Apple产品完全忽略了无缓存，无存储，过期：0或其他任何您可能尝试强制使用的标头他们不会重复使用过期的表格页面。
这让我们头疼不已，因为我们试图让用户的iPad问题，在他们通过表单流程到达的页面上保持睡眠状态，比如说第2步，然后是第3步，然后设备完全忽略了存储/缓存指令，据我所知，只需从页面的最后一个状态获取页面的虚拟快照，即忽略明确告知的内容，而且不仅仅是一个不应该存储的页面，并存储它而不再实际检查它，这会导致各种奇怪的Session问题，等等。
我只是添加这个以防万一有人出现并且无法弄清楚他们为什么会遇到尤其是iphone和ipads的会话错误，这似乎是这个领域中最严重的违规者。
我已经针对这个问题进行了相当广泛的调试器测试，这是我的结论，设备完全忽略了这些指令。
即使是经常使用，我也发现有些手机也完全无法检查新版本，比如说，Expires：0然后检查最后修改日期以确定它是否应该换新版本。
它根本不会发生，所以我被迫做的是将查询字符串添加到我需要强制更新的css / js文件中，这会诱使愚蠢的移动设备认为它是一个文件它没有，例如：my.css？v = 1，然后v = 2用于css / js更新。这很有用。
顺便提一下，如果保留默认值，用户浏览器截至2016年，因为我不断发现（我们对我们的网站进行了大量更改和更新）也无法检查此类文件的最后修改日期，但查询字符串方法修复了该问题。这是我注意到的客户和办公室人员，他们倾向于在浏览器上使用基本的普通用户默认设置，并且没有意识到css / js等缓存问题，几乎无法获得新的css / js更改，这意味着他们的浏览器的默认值（主要是MSIE / Firefox）没有按照他们的要求做，他们忽略更改并忽略上次修改日期并且不验证，即使明确设置了Expires：0。
这是一个很好的技术信息很好的线程，但同样重要的是要注意这些东西在特别是移动设备上的支持有多糟糕。每隔几个月我就必须添加更多层保护，以防止他们无法遵循他们收到的标题命令，或者正确地插入这些命令。
答案 7 :(得分：0)
不同之处在于no-cache（Firefox上没有存储）会阻止任何类型的缓存。这对于防止将安全内容写入磁盘的页面以及即使使用后退按钮重新访问它们也应始终更新的页面非常有用。
max-age = 0表示缓存条目已过时且需要重新验证，但不会阻止缓存。浏览器通常每个浏览器会话只验证一次资源，因此在新会话中访问该站点之前，内容可能不会更新。
通常，浏览器不会删除过期的缓存条目，除非它们在浏览器缓存已满时回收更新内容的空间。使用no-store，no-cache允许显式删除缓存条目。
答案 8 :(得分：0)
我正在写一系列文章，深入探讨这些主题，恕我直言，显然开发人员之间的讨论不够。
浏览器，代理和CDN：
https://medium.com/free-code-camp/http-caching-in-depth-part-1-a853c6af99db
telnum和dfB['telnum']
https://medium.com/@lojacquemin/an-in-depth-introduction-to-http-caching-cache-control-vary-e3229815ddf4
答案 9 :(得分：0)
（令人惊讶地）未提及的一件事是，请求可以使用max-stale指令显式指示它将接受陈旧数据。在这种情况下，如果服务器用max-age=0进行响应，则缓存将仅考虑响应过期，并且可以自由使用它来满足客户端的请求（该请求要求潜在的过期数据）。相比之下，如果服务器发送的no-cache实际上确实胜过客户端（使用max-stale的任何请求），则必须重新验证缓存。