页面 HTML 引用 /static/version123/,刷新后又变成 version456,CSS/JS 随机 404。多节点各自执行 static-content:deploy 或版本文件不同,会让 HTML 与静态目录无法配对;CDN 还可能缓存两套响应。
固定复现条件
连续请求记录响应节点、HTML 中 static version、静态 URL 状态和发布 release。比较所有节点的 pub/static/deployed_version.txt、静态目录和代码构建哈希。
cat pub/static/deployed_version.txt
find pub/static -maxdepth 2 -type f | head
sha256sum pub/static/deployed_version.txt composer.lock app/etc/config.php
curl -sk https://shop.example.com/ | grep -o 'static/version[0-9]*' | sort -u
curl -skI https://shop.example.com/static/version123/frontend/Vendor/theme/en_US/css/styles.css
根据证据定位
节点独立部署会生成不同版本;共享 HTML 缓存与本地静态文件组合也会错配;CDN 先切 HTML 后上传资源会产生短暂 404。仅清浏览器缓存无法修复。
修复与回滚
在单一构建阶段生成静态产物和版本文件,作为不可变 release 分发到所有节点。先让新资源在源站/CDN 可用,再原子切换应用与 HTML 缓存;不要让每台生产节点自行生成。
验收
连续命中所有节点只出现一个版本,旧页面引用在回滚窗口仍可访问;无痕、CDN HIT/MISS 和两个 Store locale 均无 404。
生产环境操作前的检查
处理“Magento 2 多节点静态资源签名不一致”前,先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT;写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、app/etc/env.php 配置摘要和实际流量节点。
php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status
命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复;涉及客户、支付、税费、库存或订单的变更,应先在脱敏数据副本验证。
建立可比较的排查记录
每次实验只改变一个变量,记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象;旧对象恢复而新对象仍能复现,说明根因尚未消除。
| 检查层 | 证据 | 通过标准 |
|---|---|---|
| 入口 | URL、状态码、请求 ID、节点 | 路由与协议一致 |
| 应用 | 异常堆栈、模块、作用域 | 无新异常且可重复 |
| 数据 | 主键、时间、关联行数 | 关系完整无重复副作用 |
| 业务 | 正常、失败与重试路径 | 最终状态一致 |
修复后的观察窗口
上线后至少观察一轮 Cron、队列和索引周期,并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏,确认错误率、响应时间和数据量稳定后及时关闭。

