在 Magento 2 中执行 bin/magento cache:clean 后页面仍然是旧内容，并不代表命令没有生效。一次前台请求可能依次经过 CDN、Varnish、Magento Full Page Cache、Block HTML、Redis 和浏览器缓存。只清理其中一层，旧响应仍可能从上一层返回。最有效的办法不是反复执行 flush，而是先确认旧内容由哪一层提供。

先做一个不会破坏生产缓存的对照请求

选择一个仍显示旧内容的页面，用查询参数绕过已有的 URL 缓存键，并同时查看响应头：

curl -sSI 'https://shop.example.com/category.html?cache_test=20250307'
curl -sS  'https://shop.example.com/category.html?cache_test=20250307' | grep -n '旧文案'

重点看 Age、X-Magento-Cache-Debug、X-Cache、CF-Cache-Status 等字段。如果普通 URL 是旧内容，而带随机参数的新请求已经更新，问题通常在 Varnish 或 CDN；两个请求都旧，再查 Magento 与数据源。

确认清理的是正确实例和正确缓存类型

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

cache:clean 只删除 Magento 标记为相关的缓存条目；cache:flush 会清空当前缓存存储，若同一个 Redis DB 被其他应用共用，flush 可能误伤，所以生产环境不要把它当作常规第一步。多台 Web 节点还要确认命令运行目录与线上节点使用的是同一份 app/etc/env.php。

可对比每台节点的部署版本和配置摘要：

pwd
sha256sum app/etc/env.php
php bin/magento --version
grep -R "cache" -n app/etc/env.php

Redis 中是否存在旧前缀

先从 env.php 读取 Redis 的 host、port、database 与 id_prefix，再对对应 DB 做只读检查。不要在大库上执行 KEYS *：

redis-cli -h 127.0.0.1 -p 6379 -n 1 INFO keyspace
redis-cli -h 127.0.0.1 -p 6379 -n 1 --scan --pattern 'zc:*' | head

如果新旧节点使用不同的 database 或 id_prefix，你在 A 节点清理的缓存不会影响 B 节点。修正配置后先维护模式切流，再清理相关缓存，避免不同节点继续写入两套键空间。

Varnish 与 CDN 分开验证

绕过 CDN，直接请求源站或负载均衡的内网地址，同时保留 Host：

curl -sSI -H 'Host: shop.example.com' http://10.0.2.15/category.html
curl -sS  -H 'Host: shop.example.com' http://10.0.2.15/category.html | grep '新文案'

源站已新、公网仍旧，就不应继续清 Magento。Varnish 可检查 BAN/PURGE 是否到达以及对象命中情况；CDN 则按具体 URL 或标签刷新。若响应头的 Age 不断增长，说明旧对象确实还在代理层。

只有某个浏览器旧时检查静态资源和 Service Worker

打开无痕窗口测试，再在开发者工具 Network 中禁用缓存。如果 HTML 已更新但 JS/CSS 仍旧，核对页面引用的静态版本号：

php bin/magento config:show dev/static/sign
find pub/static -maxdepth 2 -name deployed_version.txt -print -exec cat {} ;

PWA 或自定义主题注册过 Service Worker 时，还要在 Application 面板中查看 Cache Storage。仅当确认旧文件由 Service Worker 返回时再注销它，不能用“让所有客户清浏览器缓存”代替修复发布流程。

最后用三种请求回归：公网普通 URL、公网随机参数 URL、源站 Host 请求。三者都出现新内容，且连续两次访问能正常 HIT，才说明缓存链路恢复完整。