同一个可配置商品，红色子商品比蓝色贵 20 元，但前台切换颜色后价格一直不动。这个问题不要一上来重写 swatch 组件，先判断浏览器拿到的价格数据是不是就已经错了。

先在页面源码里找子商品价格

查看可配置商品初始化 JSON，重点看 attributes、optionPrices 和子商品 ID 的对应关系。两种颜色的 optionPrices 本来就相同，问题在服务端价格计算或索引；JSON 里价格不同但页面不变，才是前端事件没有驱动 priceBox。

同时确认子商品的 website、客户组价格、special price 日期和货币。后台看到的基础价格不一定等于当前客户组最终价格。

bin/magento indexer:reindex catalog_product_price
bin/magento cache:clean block_html full_page

只在索引确实缺失时执行，不要把这两条当成固定仪式。重建前后都应该对比初始化 JSON，否则无法证明是索引修好的。

JSON正确时，跟着change事件往下查

在浏览器 Console 观察选择颜色后是否选中了对应 simple product，页面有没有 JavaScript 异常。第三方主题经常复制旧版 configurable.js 或 swatch-renderer.js，升级 Magento 后方法签名变了，错误被其他脚本吞掉，只剩价格不更新。

检查 priceBox 节点的 data-role 是否仍然存在，是否出现两个相同 ID 的价格容器。快速购买、Sticky Header 或自定义图库可能克隆了表单，事件更新的是隐藏区域，用户看到的那一块自然不变。

别把所有差价都写进前端脚本

有人为了赶进度在 onchange 里手工加 20 元，这会绕过客户组价格、税、货币格式和促销规则。正确修复应该让前端使用 Magento 输出的最终价格结构，只修复选项到商品 ID 的解析或 priceBox 更新链路。

最后测试不仅要点颜色，还要覆盖颜色+尺寸组合、缺货组合、登录客户组和含税显示。若只有某个组合不更新，通常是允许组合索引或子商品数据问题；若所有组合都不更新，才集中查主题 JS。这样排查比“索引和静态资源全清一遍”更容易留下可复现的结论。