网站内容改了仍显示旧版：
采购怎样验收缓存更新？

网站内容已经修改，客户却仍看到旧版，验收不能止于“我这里刷新正常”。旧内容可能在浏览器里、CDN 节点上，也可能根本没有发布到正式环境；页面正文是新的，配图或样式却还旧，又是另一类问题。采购方应要求服务商证明一次更新如何贯穿页面、资源和访问路径，而不是把清浏览器缓存变成客户必须配合的售后动作。

一、这次更新要以哪一份内容版本作为签收基准？

先把“改好了”转换成可核对的对象。记录正式网址、修改部位、期望文案或文件、发布版本及对应资源地址。产品规格变了，验收基准就是新规格；目录下载更新了，则要核对下载文件里的修订内容，而不是只看按钮文字。发布日期不能独自证明版本正确，因为日期和正文可能分别生成。

技术交付可附部署标识或发布清单，将 HTML 与其引用的样式、图片、脚本、文档归到同一版本。采购方不必阅读全部源码，但应能从记录确认“这次应该看到什么”。如果只改图片、沿用旧文件名，就要明确依赖怎样更新；若正式环境仍拿着旧发布包，清再多缓存也不会得到新版。

还要列出客户实际入口：首页导航、收藏网址、邮件中的产品链接和目录下载入口。验收用这些入口进入，不能只用带临时参数的测试网址。预览域名显示新内容，只证明预览部署存在，不证明正式域名、重定向后的地址及下载文件都已更新。

二、客户看旧版时，应该让服务商先查哪一层？

先收集完整 URL、发现时间、浏览器和具体旧内容，再比较正式部署产物、公共访问响应与浏览器实际显示。开发者工具的 Network 面板可以记录响应头、状态码，以及资源来自网络、内存还是磁盘缓存。截图帮助确认现象，却无法独自定位层级；不要第一步就要求客户清除全部浏览数据。

浏览器与 CDN 不是同一个可远程清空的仓库。CDN 清除针对共享缓存，不能据此宣布客户设备上的副本已更新。如果站点装了 Service Worker，还可能由它自己的缓存策略提供旧页；没有此机制就不用凭空增加排查步骤，有则必须交付更新、失效及恢复的说明。

三、页面和资源应该采用同一套缓存交付规则吗？

不应该。客户长期收藏的 HTML 地址通常保持稳定，需要有明确的更新检查机制；带内容哈希的图片、样式和脚本则可以用较长缓存期，因为内容变化时换新地址。把 HTML 当成不会变化的资源长期强缓存，会让浏览器根本不请求新页面，也就不知道页面引用了新资源。

“The no-cache directive does not prevent the storing of responses but instead prevents the reuse of responses without revalidation.”

MDN 说明，no-cache 不是禁止存储，而是要求复用前重新验证。采购方应验收实际响应与更新行为，不能按指令名称理解成“已经完全关闭缓存”。

MDN · HTTP 缓存

让服务商按资源类型列明浏览器策略与 CDN 策略。max-age 与 s-maxage 分别涉及不同缓存范围，平台规则还可能影响边缘行为，因此必须查看实际响应，而非仅看配置截图。个性化页面不能复用公开页面的共享缓存规则；涉及账户或私有内容时，还需明确访问控制及 private、no-store 等处理。

ETag 或 Last-Modified 可用于条件验证。返回 304 表示验证器认为内容未变，浏览器继续使用已有响应，它不是旧版的直接证据；也不是新版的直接证据。验收必须对照内容和验证器，如果文件已改而 ETag 没有正确变化，就要修复生成或中间缓存的逻辑。

四、服务商说资源带版本参数，就能批准更新验收吗？

版本参数只有实际参与缓存键并随内容变化，才有意义。如果 CDN 忽略查询字符串，两个带不同参数的地址仍可能共用一份副本。让对方出示当前缓存键规则，并用修改前后的资源地址核对响应内容；不能把“网址里多了一串数字”视为已经完成版本管理。

内容哈希文件名更容易把版本关系表达清楚，但它也要遵守“不在同一地址下替换不同内容”的约定。HTML 引用新文件前，新资源必须已经可访问；旧资源应按兼容旧页面的需求保留，而不是发布完立即删除。否则仍持有旧 HTML 的客户会得到资源缺失，这不是简单的旧版问题。

下载目录和规格书可以交付为带修订版本的文件，并让稳定入口引用当前版本。采购验收同时检查链接和文件内容，防止按钮写着新版、下载到的仍是旧文档。若必须沿用同一下载地址，就把重新验证与 CDN 清除列入发布动作，别只给页面追加版本参数。

五、点击了 CDN 清除按钮，还要索取什么证据？

要求清除记录写明目标 URL、环境和有关缓存变体。正文改动至少涉及该页面，公共片段变动则可能涉及多页，图片另有其资源地址。按实际范围清除，不需要每次清空全站；使用自定义缓存键时，应确认清除方法覆盖对应请求头或查询条件形成的变体。

“This indicates that Cloudflare received the request — it does not confirm that Cloudflare cached the targeted content or evicted any content.”

这句解释的是清除请求返回 HTTP 200：平台收到了请求，并不等于目标缓存确实存在或已被移除。所以验收要继续取回资源核对，不能只交一张接口成功截图。

Cloudflare · 清除缓存

清除后应请求目标资源，记录缓存状态并核对新版内容。首次请求的状态和后续命中新副本的状态可能不同，不能要求以后永远不能 HIT；真正要证明的是命中的副本属于新版。平台处于 HIT 也不必然是故障，缓存状态、响应内容和发布标识必须一起看。

六、怎样设计测试，才不是只验证新访客看见新版？

发布前在测试浏览器访问旧页，保留它的真实缓存；发布后用同一浏览器再次通过正常入口访问，另外用新会话和不同网络作对照。旧会话检验更新能力，新会话检验公共响应，二者缺一不可。强制刷新和开发者工具禁用缓存适合诊断，不应成为唯一通过条件。

分别检查正文、图片、样式及下载文件，按变更清单逐项确认。再测试前进后退：MDN 提醒历史导航可能恢复页面快照，不一定执行 HTTP 重新验证。若采购需求涉及实时有效的告知或交易状态，应另定重新进入页面时的检查行为，不能承诺所有仍打开的旧标签会自动更新。

验收窗口也应根据内容用途提前约定。一般宣传文案可按既定更新检查规则验证，失效告知或规格纠错则应明确采取哪些发布和清除动作；不要在错误发生以后才临时决定“等缓存自然过期”。已经下载到客户设备的文档也不会因网站换版自动被替换，必要时由业务部门补充告知。

出现新正文配旧图片等混合版本时，先对照资源请求和 HTML 引用，而不是笼统归为“客户缓存”。测试报告应写明路径、看到的版本、请求证据和未覆盖范围。既没有复现又没有说明的“偶发”应作为待观察项，给出下一次收集证据的办法和责任人。

七、采购托管方案时，怎样约定更新完成和回退边界？

采购 Edge-First 外贸独立站托管方案时，把内容更新的签收点写成“正式入口获取正确页面及依赖资源，并完成旧会话验证”。交付应包含资源命名规则、缓存分层策略、清除权限、发布记录与回退版本；不要把刷新客户设备作为交付条件，也不要用一个性能评分代替版本验收。

回退时同样处理 HTML、资源及共享缓存，确认旧版本引用的文件仍在。采购方批准的是具体版本恢复，不是“再清一次试试”。缓存方案做得可交付，关键不在于缓存开得多或少，而在于每次内容变化都有一致的版本关系、明确的更新路径和可复核的签收证据。