发布新主题后，服务器上的文件已经变化，客户页面却仍执行旧 JavaScript。让所有人“强制刷新”只能绕过单个浏览器，不能证明 CDN 或 Web 节点已经切到新资源。
先选一个有明确改动的资源
不要拿合并后的随机文件猜。选一个本次确实改过的 JS/CSS，在源码中放入可搜索的版本标记，例如模块版本号或一段不会影响功能的注释。然后从页面 HTML 复制它实际请求的完整 URL。
curl -sS -D /tmp/static.headers -o /tmp/static.body 'https://www.example.com/static/version123/frontend/Vendor/theme/zh_CN/js/app.js'
sha256sum /tmp/static.body
grep -n 'release-20241230' /tmp/static.body
sed -n '1,40p' /tmp/static.headers响应头中的 Age、X-Cache、ETag、Last-Modified 能说明对象来自哪一层。URL 里仍是旧的 version...，先查 HTML/FPC；URL 已是新版本但 body 旧，查 CDN、Nginx 或错误源站文件。
直接对比 CDN 与源站，避免猜测
知道源站 IP 时，可在受控终端用 --resolve 保持 Host 和 TLS 名称不变：
curl -sk --resolve www.example.com:443:ORIGIN_IP -o /tmp/origin.js 'https://www.example.com/static/version123/frontend/Vendor/theme/zh_CN/js/app.js'
sha256sum /tmp/origin.js /tmp/static.body源站新、CDN 旧：精确 purge 当前资源或版本目录；源站也旧：继续检查 release。不要先全站 purge，因为这会制造缓存击穿，还会把定位证据清掉。
确认运行 release 里究竟有什么
readlink -f /var/www/current
find pub/static/frontend/Vendor/theme/zh_CN -type f -name 'app.js' -ls
grep -R 'release-20241230' pub/static/frontend/Vendor/theme/zh_CN/js
bin/magento config:show dev/static/sign常见错误是先切换 current 软链接，再在旧目录执行 static deploy；或者多台 Web 节点只有一台更新。逐台输出 release ID 和文件哈希，轮询访问时在响应头加入脱敏节点标识，很快就能看到是否某一台在返回旧资源。
正确的构建顺序
composer install --no-dev --prefer-dist --no-interaction
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f zh_CN en_US
bin/magento cache:clean config layout block_html
# 健康检查通过后，再原子切换 current 到新 release静态内容应在独立 release 中构建完成，不能一边被请求一边覆盖。pub/static/.htaccess、主题 locale 和部署 mode 也要跟随发布产物。
如果 URL 签名没变
静态签名开启后，新部署通常应产生新的版本路径。签名仍旧，检查 deployed_version.txt、共享的 pub/static、只读文件系统和发布用户权限。不要手工改 HTML 里的版本号；版本必须与实际目录和回源 rewrite 一致。
最终用一个全新资源 URL完成三点证明：HTML 引用新签名、CDN 与源站文件哈希相同、连续访问命中缓存。这样即使不清浏览器，也能确认问题真正解决。
