Headless Commerce 库存与价格同步上线前 QA 检查清单

Headless Commerce 的库存问题通常不是从商品页开始的。真正的问题经常出现在 Shopify、ERP、仓库系统、CMS、价格规则和前端缓存都认为自己拥有一部分商品事实的时候。

一个店铺在 staging 里看起来没问题，但上线后仍然可能卖错变体、显示过期库存、隐藏其实有货的商品，或者把价格不一致的问题带到结账。无论是上线 Headless Shopify 店铺、接入库存系统、增加市场价格，还是准备一场库存敏感的大促，都应该先跑这份清单。

不要一开始就在前端页面上点来点去。先写清楚每个字段由哪个系统负责。库存数量可能来自仓库系统，价格来自 Shopify，套装可售状态来自应用，履约规则来自 OMS，商品编辑内容来自 CMS。

这张数据源头表要简单到运营、开发和客服负责人能一起看懂。如果没人能说明字段冲突时哪个系统优先，QA 最多只能发现表面症状。

• 梳理 SKU、变体 ID、条码、商品 handle、选项名称、库存策略、履约地点、价格、划线价、市场价格、订阅计划和套装规则。
• 记录每个字段的同步方向：单向、双向、手动导入、Webhook、定时任务，或请求时实时读取 API。
• 写清每个系统的负责人，以及谁能批准上线前的紧急修正。
• 标记哪些字段可以延迟，哪些字段必须按收入关键数据处理。

一个测试商品无法暴露同步边界问题。你需要做一组小矩阵，覆盖真实目录里的商品逻辑。目标不是测试每个 SKU，而是测试店铺必须理解的每一种商品规则。

尽量使用真实商品。如果目录里暂时没有某个边界场景，就在 staging 里创建专门的测试记录。这份矩阵后面在大促前、ERP 调整、Shopify 应用变化和前端缓存更新时还能继续用。

• 有货普通商品、无货普通商品和低库存商品。
• 多变体商品、部分不可售变体、改名后的选项，以及变体图片不匹配的商品。
• 带划线价的促销商品、定时改价商品、市场专属价格和货币转换。
• 预售、缺货可下单、按单生产、套装、订阅、数字商品，以及多个地点履约的商品。
• 搜索隐藏商品、未发布商品、停产商品，以及缺少可选数据的商品。

库存 QA 必须跟着客户路径走。商品卡片可能显示可购买，但 PDP 阻止购买。PDP 可能允许选择一个结账会拒绝的数量。用户在另一个标签页里开始结账后，购物车可能仍然保留已经不可售的商品。

把每种库存状态都放到商品详情页、集合卡片、搜索结果、推荐模块、购物车抽屉、结账跳转、订单确认，以及任何展示可售状态的商品 Feed 或活动页里检查。

• 确认无货标签、禁用按钮、变体选择器、低库存提示和到货通知状态都和来源系统一致。
• 测试修改数量、快速多次加入购物车、多个浏览器标签页，以及库存变化前已经开始的结账流程。
• 检查地点级库存是否影响配送承诺、自提选项和送达信息。
• 确认不可售变体不会以破坏深链接、SEO 元数据或用户预期的方式直接消失。

价格同步需要单独的 QA 路径，因为店铺可见价格不一定等于最终商业事实。市场、币种、客户分组、折扣、税费、订阅、套装和结账规则都可能改变用户看到的价格。

用同一组商品矩阵去对比商品卡片、PDP、购物车、结账、订单确认、分析事件和结构化数据。如果这些位置不一致，就要判断是前端展示错了，还是同步协议本身没有定义清楚。

• 检查原价、划线价、促销价、阶梯价、订阅价、套装价和客户专属价格。
• 在活动开始前、活动进行中和活动结束后测试定时改价。
• 跨币种、市场、含税地区和不含税地区对比价格。
• 确认折扣码、自动折扣、赠品逻辑和结账脚本不会制造价格不一致。
• 检查分析事件和商品 schema，确保上报价格与可见价格一致。

只有在每个 Webhook 都准时到达时才正常工作的同步，还不能上线。真实系统会重试任务、丢失 payload、遇到 rate limit、收到部分更新，或者按错误顺序处理变化。

上线前要让团队一起看日志，做几组可控失败测试。目标是知道哪里会坏、问题是否可见、谁会收到告警，以及团队如何在不靠猜的情况下恢复。

• 延迟或重放一次商品更新，确认前端最终能到达正确状态。
• 如果基础设施支持，触发 Webhook 失败、队列重试、rate limit 和手动重新同步。
• 在很短时间内同时更新价格和库存，捕捉顺序问题和缓存过期窗口。
• 检查失败任务是否会出现在日志、告警、仪表盘或 dead-letter queue 里。
• 记录单个 SKU、一组商品和全目录重新同步的手动修正路径。

库存和价格错误也会影响 SEO 与商品运营。Product schema 可能显示错误可售状态。站内搜索可能继续推荐无货商品。集合排序可能把有货商品埋掉。商品 Feed 可能把过期价格同步到购物渠道。

每完成一个重要同步测试，都要同时检查渲染后的页面和周边数据。这也是 Headless QA 和技术 SEO、投放、商品运营重叠的地方。

• 确认 schema 里的 availability、price、currency、URL、image 和 variant 数据与线上商品状态一致。
• 库存变化后检查集合排序、筛选、搜索结果、推荐模块和相关商品。
• 商品 handle 或变体 URL 变化后，验证 canonical URL 和重定向是否干净。
• 确认商品 Feed 和活动导出不会发布过期价格或可售状态。
• 提前决定停产商品应该如何处理：继续保留、重定向、显示不可售、从列表移除，或返回明确状态。

再好的同步 QA 也需要上线周监控。商品数据上线后仍会变化，第一批真实订单也会暴露 staging 没有覆盖的情况。监控应该关注数据不一致信号，而不只是服务器是否在线。

准备一份首日重点检查商品和流程清单。包括畅销品、促销品、低库存商品、多地点履约商品、套装、订阅，以及任何承接付费流量的商品。

• 监控 API 错误、Webhook 失败、队列积压、缓存重新验证失败、404、结账拒绝，以及提到库存或价格的客服工单。
• 按固定时间抽样对比前端数值和来源系统数值。
• 把手动清缓存、手动商品重同步、回滚和事故负责人信息放在同一个地方。
• 给客服准备价格不一致、超卖、无货结账和履约延迟问题的回复脚本。