用POST请求同一URL清除缓存：规范里提到的方法为什么难落地

如果你更新了服务器上的页面，但用户浏览器或中间缓存里还存着旧版本，你可能会想找一个“删除缓存”的接口。按 MDN 的 HTTP 缓存说明，HTTP 缓存规范本质上没有定义显式删除缓存的方法。

原因在于缓存的设计目标：缓存存储与请求关联的响应，并将存储的响应复用于后续请求，从而减少对源服务器的访问。一旦响应被存储，服务器就无法再对它做任何操作——因为由于缓存，不再有请求到达服务器。

这就是问题的起点：不是某个指令写错了，而是规范没有提供“主动删除”这个动作。本文只讲规范里提到的两种与“覆盖或清除已存储响应”有关的方式：用不安全方法请求同一 URL，以及 Clear-Site-Data。不讲 max-age 怎么设置，也不讲 CDN 的清除操作。

一个前提：下面所有场景都是编辑设计的自建示例，用于说明概念，不是对某个真实站点的测试记录。

规范中提到的方法之一是：使用不安全的方法（例如 POST）发送对同一 URL 的请求。

这里的“不安全方法”指的是会改变服务器状态的方法，POST 是常见的一种。它的思路是：缓存按 URL 存储响应，那么用一个 POST 请求打到同一个 URL，如果这个请求被处理并返回了新的响应，这个新响应就可能覆盖掉原来存储的那一份。

需要说清楚的是，MDN 的表述是“规范中提到的方法之一”，并紧接着说明“但对于许多客户端而言，这很难实现”。也就是说，规范提到了这个方向，但它并不是一个被普遍实现、可以放心依赖的机制。

一个自建示例（仅用于理解概念，不是可执行的真实操作）：假设你在练习目录里维护一个自建页面，地址是 example.test/notes。你希望用 POST 请求 example.test/notes 来触发一次覆盖。这个示例只用来对照“同一 URL、不安全方法”这两个条件，不涉及任何真实服务器配置。

本文只解释这个方法在规范里的位置和它的实现难点，不提供绕过缓存的具体代码，也不声称它一定有效。

“很难实现”不是一句笼统的抱怨，可以拆成几个具体卡点。

第一，谁来发这个 POST。缓存可能存在于浏览器、代理、托管缓存等多个位置。规范提到的方法需要有一个客户端主动发出这个不安全请求。但普通用户不会为了刷新一个页面去手动发 POST。

第二，缓存是否按这个方法覆盖。规范提到这个方法，并不等于所有缓存都会照做。资料只写到“对于许多客户端而言，这很难实现”，没有说明覆盖是否取决于具体缓存的实现，本文也不替它补这一层。

第三，中间缓存不受你控制。共享缓存位于客户端和服务器之间，可以存储能在用户之间共享的响应，进一步分为代理缓存和托管缓存。托管缓存由服务开发人员明确部署，特性因部署的产品而异。你无法保证路径上的每一个中间缓存都按你的预期处理这个 POST 请求。

所以这个方法难落地的核心，不是语法问题，而是它依赖“客户端愿意发、缓存愿意覆盖、中间层都配合”这三个条件同时成立。

另一种与清除缓存有关的方式是 Clear-Site-Data: cache 标头及其指令值。

按 MDN 的说明，Clear-Site-Data: cache 可用于清除浏览器缓存——但对中间缓存无效。这句话给出了一个明确的边界：它作用在浏览器这一层，也就是私有缓存；它管不到位于客户端和服务器之间的共享缓存。

为什么这个边界重要：如果你更新了内容，用户浏览器里还存着旧版本，Clear-Site-Data 有可能帮助清掉浏览器里那一份。但如果旧响应同时被某个中间缓存存着，并且后续请求命中了那个中间缓存，那么即使浏览器这一层被清掉，用户拿到的仍可能是中间缓存里的旧内容。

资料还写明：响应将一直保留在浏览器缓存中，直到 max-age 过期为止，除非用户手动执行刷新、强制刷新或清除历史记录操作。本文只讲 Clear-Site-Data 对浏览器缓存有效、对中间缓存无效这一条边界，不讲 max-age 怎么设，也不讲任何 CDN 的清除操作。

把上面两条放在一起，可以整理成一张自建的核对表，用来判断你遇到的问题落在哪一层。以下表格是编辑整理的判断方向，不是对某个真实系统的检测记录。

| 观察到的现象 | 更可能涉及哪一层 | 规范里提到的方式能否覆盖 |

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

| 只有你这台设备看到旧内容，换设备或换网络看到新内容 | 浏览器私有缓存 | Clear-Site-Data 可能清掉这一层 |

| 多台设备、多个网络都看到旧内容 | 中间共享缓存 | Clear-Site-Data 无效；POST 覆盖依赖中间缓存是否配合 |

| 用户手动强制刷新后看到新内容 | 浏览器这一层 | 属于用户手动操作，不是服务器主动清除 |

使用这张表时注意两点。第一，它只帮你缩小范围，不能替你确认某一层缓存的具体实现。第二，表格里的“可能”“依赖”这些词是刻意的——规范没有承诺这两种方式在所有客户端和所有缓存上都生效。

一个自建示例：假设你在练习目录里维护一个自建页面，先在本机浏览器看到旧内容，再用另一台设备访问同一地址看到新内容。按这张表，优先怀疑本机浏览器缓存，而不是服务器没更新。这个示例只用于演示判断顺序。

如果你的目标是“服务器一更新，所有缓存立刻失效”，那么上面两种方式都不足以支撑这个目标。

规范没有定义显式删除缓存的方法，这是前提。POST 覆盖依赖客户端和缓存的配合，Clear-Site-Data 只管浏览器这一层。两者都不是“主动删除所有已存储响应”的通用手段。

MDN 给出的方向是：如果服务器不想失去对 URL 的控制——例如在资源被频繁更新的情况下——应该添加 no-cache，以便服务器始终接收请求并发送预期的响应。这句话的重点是“让请求回到服务器”，而不是“事后去删缓存”。

所以判断顺序可以这样定：先问自己能不能接受“让每次请求都回源验证”，如果能，方向是调整响应头。资料还提到，托管缓存可以通过仪表板操作、API 调用、重新启动等方式实时删除已经存储的响应，这属于你所使用的托管缓存自己提供的接口，不在本文范围内展开。

本文只讲规范提到的这两种方式为什么难落地，以及由此得出的判断方向。不讲 max-age 设置，不讲 CDN 清除操作，也不推荐任何具体产品或服务。