后台改了 CMS Block，也执行了 cache:clean，页面还是昨天的内容。缓存层多的时候，“我清过缓存”没有诊断意义，先确认当前响应究竟从哪一层返回。

用响应头判断谁在回答

curl -sI https://shop.example.com/page | egrep -i 'age|x-cache|x-magento-cache-debug|x-magento-tags|via'
curl -s https://shop.example.com/page -o /tmp/page.html

连续请求比较 Age、HIT/MISS 和 Magento 缓存调试头。绕过 CDN 直连 Varnish，再绕过 Varnish 直连源站，直到看到新内容。在哪一跳从新变旧，就查那一层，而不是从浏览器一路清到 Redis。

缓存Tag有没有传到Varnish很关键

Magento 更新 Block 时依赖相关 identity/tag 失效页面。如果自定义 Block 没实现正确 identity，或者 Nginx/CDN 删除了 X-Magento-Tags、PURGE/BAN 没到 Varnish，后台清理只能影响 Magento 自身缓存，外层对象仍然存活。

检查该页面缓存对象是否带有 CMS Block 对应标签，以及保存 Block 后 invalidation 请求是否成功。不要把标签头直接暴露给公网，但内部代理链要能使用它。

同名Block和Store View也会制造“缓存没清”的错觉

多商店里可能有相同 identifier 的不同 Block。后台改的是 Default Store View，页面实际读取另一个 store scope；或者 Page Builder 内容嵌入了另一块。直接在页面 HTML 找一段唯一文本，再回后台确认具体 block_id。

浏览器 Service Worker、CDN Edge 和 Varnish 的 TTL 也要分开。用 curl 得到新内容而用户浏览器仍旧，再查浏览器缓存；公网 CDN 旧、源站新，则做精确 URL purge，避免全站清缓存造成无谓回源峰值。

修复后保存同一 Block 两次，每次用唯一标记验证各层在合理时间内更新，并确认其他页面没有被全部驱逐。目标不是“清得越彻底越好”，而是让正确的 Tag 精准失效。