主题大部分是中文，结账组件少数字段却显示英文，而且每次发布后出现的位置不一样。通常是静态部署的locale、主题继承和翻译JS字典没有一起生成。

问题不在表面

先用一个真实失败样本复现，不要一上来全量重建。把请求、实体ID和时间记下来，后面的SQL与日志才能对得上。

几条命令足够定位

  • 查看页面加载的是哪个js-translation.json，状态码和内容是否对应当前主题。
  • 确认部署命令是否只写了语言参数却漏了主题或area。
bin/magento config:show general/locale/code
find pub/static -path "*zh_CN*js-translation.json" -ls
bin/magento setup:static-content:deploy -f zh_CN en_US --area frontend --theme Vendor/theme
bin/magento cache:clean translate full_page

这里的重点不是把报错暂时消掉，而是让同一操作再执行一次仍保持幂等；因此修复后一定要做第二次重复执行测试。

改动落在哪里

生产模式先维护窗口删除目标主题对应的pub/static/frontend/Vendor/theme目录（保留.htaccess），再带正确area、theme与locale部署。自定义翻译放i18n/zh_CN.csv并检查引号转义；RequireJS组件中的文案必须通过$.t()进入字典。多节点要共享或同步同一构建产物。

实施时的顺序

  • 先做数据与配置备份，记录当前值。
  • 只改一个变量并重跑失败样本。
  • 确认新数据正确后，再处理历史受影响记录。
  • 最后恢复定时任务或缓存。

验收清单

  • js-translation.json含目标词条
  • 硬刷新与无痕访问都为中文
  • 结账懒加载组件也正确
  • 下次发布结果可重复

验收不只看后台提示“成功”。我还会从前台/API再走一次真实链路，并在下一轮cron、索引或缓存命中后重复检查，确认不是短暂正常。

不要这样处理

不要直接在线修改pub/static生成文件，下次deploy一定会覆盖。

如果线上数据已经不一致，先停掉会继续扩大差异的入口，再修历史数据；否则一边补一边写，最后很难判断哪些记录已经处理。