商品价格、CMS 内容或模板已经修改，执行 bin/magento cache:clean 后前台仍显示旧版本，这不一定说明 Magento 缓存命令失效。一个生产站点往往同时存在应用缓存、Block HTML、Full Page Cache、Varnish、CDN、浏览器缓存和静态资源缓存。只清理其中一层，其他层仍可能返回旧响应。

先判断旧的是 HTML 还是静态文件

打开浏览器开发者工具，禁用浏览器缓存后重新请求页面。如果 HTML 源代码里已经是新内容，但页面样式或脚本仍旧，问题在静态资源；如果 HTML 本身就是旧的，才继续检查 FPC、Varnish 和 CDN。不要把“页面看起来没变”直接等同于 Full Page Cache。

对 HTML 请求查看响应头中的 Age、X-Cache、X-Magento-Cache-Debug 或 CDN 自定义头。不同基础设施头名不同，但核心判断是：响应由哪一层命中，Age 是否持续增加，以及绕过代理直连源站时内容是否更新。

curl -I '页面地址'
curl -H 'Cache-Control: no-cache' -I '页面地址'

第二条命令不保证所有代理都绕过缓存，只能作为对照。生产环境不要通过随意拼接查询参数长期解决，这会制造大量独立缓存键。

cache:clean 和 cache:flush 不是同一个动作

cache:clean 按 Magento 的缓存类型和标签删除属于当前应用的数据；cache:flush 会清空整个缓存存储。如果 Redis 实例还被其他应用共用，flush 可能误删其他数据。先查看状态并针对类型清理：

bin/magento cache:status
bin/magento cache:clean config layout block_html full_page

修改产品或分类后，Magento 通常通过缓存标签使相关页面失效。自定义 Block 如果实现了错误的 getCacheKeyInfo()，或没有返回商品、分类的 identity 标签，就可能一直命中旧 HTML。此时反复 flush 只能暂时掩盖代码缺陷。

Varnish 与 CDN 的清除链路要单独验证

使用 Varnish 时，Magento 需要能向缓存节点发送 PURGE/BAN。检查 Full Page Cache 配置中的访问列表和后端地址，确认 Web 节点发出的清理请求能到达 Varnish。多台 Varnish 或 CDN 前置时，还要确认每个节点都收到失效消息。

如果源站和 Varnish 都已更新，公网仍旧，重点检查 CDN 缓存规则。CDN 可能忽略 Magento 的标签头、缓存带 Cookie 的页面，或把错误响应缓存过久。清理一个精确 URL 做对照，比一上来全站 purge 更容易判断规则是否生效，也能降低瞬间回源压力。

静态文件旧，多半与部署版本有关

CSS、JavaScript 和主题图片由 pub/static 与静态内容签名控制。修改源码后应按当前模式重新部署，不要直接编辑已发布文件：

bin/magento deploy:mode:show
bin/magento setup:static-content:deploy -f zh_Hans_CN en_US
bin/magento cache:clean

语言参数要与实际商店一致。多节点部署还必须保证生成文件和 deployed_version.txt 同步，否则请求可能在不同节点间交替得到新旧资源。浏览器 Service Worker、CDN 长缓存和 HTML 中的旧静态版本号也需要一起核对。

最后分别验证源站、Varnish/CDN 和普通浏览器三条访问路径。记录响应头、页面内容与静态文件 URL，确认修改后缓存能自动失效，而不是每次都依赖人工清空全部缓存。