PWA在某个域名下请求/graphql，却返回默认Store View的价格、货币和CMS内容。GraphQL不会仅凭浏览器页面域名自动切换，标准做法是每个请求发送Store头。

先说结论

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

定位过程

  • 直接看请求头是否有Store，以及值是store code而不是website code。
  • 检查CDN或反向代理有没有删除自定义请求头。
curl -s https://shop.example.com/graphql -H "Store: zh_cn" -H "Content-Type: application/json" --data '{"query":"{storeConfig{code base_currency_code}}"}'
curl -s https://shop.example.com/graphql -H "Content-Type: application/json" --data '{"query":"{storeConfig{code base_currency_code}}"}'
grep -R "proxy_set_header Store" /etc/nginx

日志取样要带上请求时间、Store View、实体ID和部署版本。只截一行异常往往不够，至少保留错误前后几十行，才能判断是入口参数还是后续状态被改写。

可执行方案

在GraphQL客户端公共link/middleware中从当前站点配置注入Store头，不要靠每个页面手工添加。服务端代理显式透传Store，并让缓存键包含经过白名单校验的store code；非法Store应返回明确错误或落到约定默认值。

实施时的顺序

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

上线后观察什么

  • storeConfig.code与当前站点一致
  • 同SKU在两个Store返回各自价格与URL
  • SSR和浏览器端请求头一致
  • CDN缓存不会跨Store命中

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

风险点

不要信任任意外部Store值去拼接配置路径，先与允许列表比对。