Cache-Control 里 no-cache 和 no-store 差在哪：一个要验证，一个不存储

如果你在响应头里看到 Cache-Control: no-cache，第一反应可能是“不缓存”。按 MDN 的 HTTP 缓存说明，这个理解是错的。no-cache 指令不会阻止响应的存储，它阻止的是在没有重新验证的情况下重用响应。

no-store 才是要求不存储的那一个。MDN 写得很直接：如果你不希望将响应存储在任何缓存中，请使用 no-store。

所以这两个指令回答的是两个不同问题。no-cache 回答“用之前要不要先问源服务器”，答案是每次都要问。no-store 回答“能不能存下来”，答案是不能。

一个自建情境（示例，不是对某个真实网站的记录）：你在练习目录里维护一个自建页面，服务器返回的响应头分别写成下面两种，观察浏览器开发者工具里后续请求的差别。

Cache-Control: no-cache

Cache-Control: no-store

本文只讲这两个指令在“是否允许存储”和“是否强制向源服务器验证”上的区别，以及 private 用于个性化响应的含义。不涉及 CDN 和 service worker 部署，也不讲具体缓存清理操作。

no-cache 允许响应被存储，但要求每次重用前先验证。MDN 给出的响应示例是：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
ETag: "deadbeef"
Cache-Control: no-cache

这段响应里同时有 Last-Modified 和 ETag。客户端下次请求同一个 URL 时，会带上 If-None-Match 或 If-Modified-Since 发起条件请求。如果资源没变，服务器返回 304 Not Modified，没有响应主体；如果变了，返回 200 OK 和最新版本。

所以 no-cache 的效果是：缓存里可以有一份副本，但每次使用前都要和源服务器确认一次。它换来的是“内容始终是最新的”，代价是每次都要发一次验证请求。

MDN 还提到一个等价写法：max-age=0 和 must-revalidate 的组合与 no-cache 含义相同。max-age=0 表示响应立即过期，must-revalidate 表示一旦过期就不得在没有重新验证的情况下重用。不过文档也说明，max-age=0 是早期实现无法处理 no-cache 时的变通做法，现在符合 HTTP/1.1 的服务器已广泛部署，应该只使用 no-cache。

no-store 的写法只有一行：

Cache-Control: no-store

它的要求是不把响应存储在任何缓存中。和 no-cache 相比，它少了“先存下来再验证”这一步，直接不存。

这里有一个容易误解的点，MDN 专门写了一句：no-store 指令阻止存储响应，但不会删除相同 URL 的任何已存储响应。换句话说，如果某个 URL 之前已经被缓存存过一份旧响应，后来服务器改成返回 no-store，这条指令不会把旧的那份清掉。旧响应仍然可能被重用。

MDN 对这种情况给出的替代方向是 no-cache：no-cache 会强制客户端在重用任何已存储的响应之前发送验证请求。也就是说，如果你担心的是“已经存过的旧内容被拿出来用”，no-cache 比 no-store 更直接地解决这个问题。

另一个需要知道的代价：MDN 提醒不要随意授予 no-store，因为会失去 HTTP 和浏览器提供的许多优势，包括浏览器的后退/前进缓存。文档的建议是，要获得 Web 平台完整功能集的好处，最好把 no-cache 与 private 结合使用。

no-cache 和 no-store 管的是“存不存、验不验”，private 管的是“存到哪一类缓存里”。

按 MDN 的说明，缓存分私有缓存和共享缓存。私有缓存绑定到特定客户端，通常是浏览器缓存，存储的响应不与其他客户端共享。共享缓存位于客户端和服务器之间，可以存储能在用户之间共享的响应。

如果响应包含个性化内容，而它被存进了共享缓存，其他用户可能检索到这些内容，造成无意的信息泄露。MDN 给出的处理方式是：如果响应包含个性化内容并且你只想将响应存储在私有缓存中，就必须指定 private 指令。

Cache-Control: private

这里有一个关键提醒：MDN 明确写了，个性化内容通常由 cookie 控制，但 cookie 的存在并不能表明它是私有的，因此单独的 cookie 不会使响应成为私有的。也就是说，不能因为响应里带了 Set-Cookie，就默认它不会被共享缓存存下来。

MDN 还提到请求合并这个场景：当多个相同请求同时到达共享缓存时，中间缓存会代表自己把单个请求转发到源，然后把结果重用于所有客户端。即使响应里写了 max-age=0 或 no-cache，这种合并也会发生。如果响应是针对特定用户个性化的，不希望它在合并中共享，就应添加 private 指令。

另外，MDN 在讲 no-store 时写了一句：在这种情况下，即使设置了 no-store，也必须设置 private。这说明 private 不是 no-store 的替代品，两者管的是不同的事。

下面这张对照表是编辑根据 MDN 资料整理的，不是官方分级标准，也不是对某个真实网站的测试记录。

| 指令 | 是否允许存储 | 重用前是否必须验证 | 存储范围限制 |

| --- | --- | --- | --- |

| no-cache | 允许 | 必须 | 未限定 |

| no-store | 不允许 | 不适用（因为不存） | 未限定 |

| private | 未单独限定 | 未单独限定 | 只允许私有缓存 |

读这张表时注意三点。

第一，no-cache 和 no-store 在“是否允许存储”这一列是相反的：一个允许，一个不允许。

第二，no-cache 和 no-store 在“是否必须验证”这一列不能简单对比，因为 no-store 不存储，就不存在“重用存储的响应”这个动作。

第三，private 不单独回答“存不存”或“验不验”，它只回答“存到哪一类缓存”。所以它可以和 no-cache 组合，也可以和 no-store 组合。MDN 给出的常见组合是 no-cache, private，用于既要求每次验证、又要求只存进私有缓存的个性化响应。

下面是一个自建练习场景，用来观察三个指令的差别。所有内容都是练习用的自建示例，不是对某个真实网站的记录，也不涉及任何缓存清理操作。

假设你在练习目录里放了一个自建页面，服务器返回的响应头先写成这样：

Cache-Control: no-cache
ETag: "practice-v1"

然后在浏览器开发者工具的 Network 面板里，对同一个地址连续发起两次请求，观察第二次请求的请求头里有没有出现 If-None-Match。按 MDN 对 no-cache 的说明，第二次请求应该带上验证字段，服务器如果判断资源没变，会返回 304。

接着把响应头改成：

Cache-Control: no-store

再连续发起两次请求，观察第二次请求是否还带着上一次的验证字段。按 MDN 对 no-store 的说明，响应不会被存储，所以不存在“重用存储的响应”这一步。

最后把响应头改成：

Cache-Control: no-cache, private

这个组合用于个性化响应。按 MDN 的说明，no-cache 保证每次重用前都验证，private 保证响应只存进私有缓存，不进入共享缓存。

以上观察方法都是编辑整理的，不是对某个真实网站的测试记录。实际观察结果会受浏览器实现和你的练习环境影响，本文不给出具体数值或固定结论。

本文只讲 no-cache、no-store 和 private 三个指令在“是否允许存储”“是否强制向源服务器验证”“存储范围限制”上的区别。

资料没有覆盖、本文也不展开的内容包括：CDN 和 service worker 的部署方式、具体缓存清理操作、托管缓存如何通过仪表板或 API 删除已存储的响应、以及不同浏览器在重新加载行为上的实现差异。

MDN 资料里提到托管缓存可以忽略 no-store 指令，并说明如果托管缓存故意忽略 no-store，无需将其视为不符合标准。这一点说明：no-store 的效果取决于你使用的缓存机制是否遵循标准。本文不讨论具体托管缓存的配置方式。

另外，MDN 提到某些 CDN 提供自己的标头，例如 Surrogate-Control，以及正在努力定义 CDN-Cache-Control 标头来标准化。这些内容属于托管缓存范围，本文不展开。

如果你要判断某个具体响应会被怎么处理，需要同时看响应头里写了哪些指令、请求经过哪些缓存、以及这些缓存是否遵循 HTTP 缓存规范。本文只提供前一项的判断依据。