价格与库存不一致：沿更新时间线找根因

直接判断：价格或库存不一致很少只是“Feed 填错了一格”。更常见的情况是多个系统分别持有不同时间版本：商品后台已更新，页面缓存已刷新，导出仍是旧批次，GMC 又在另一个时间抓取。没有时间线，团队只能反复手工刷新。

先做判断

先确定异常形态：

• 单个商品还是同一规则覆盖的一批商品？
• 稳定复现还是偶发？
• 只发生在促销、币种、地区或某个变体？
• 页面展示、结构化数据、购物车和结账是否给出同一结果？
• Feed 值错误，还是 GMC 抓取页面后发现冲突？

如果同一批商品同时异常，优先查规则和同步；只在特定地区发生，优先查地区定价、税费与币种；只在促销切换时发生，优先查生效时间与缓存；只影响某个变体，回到变体映射。

诊断框架：画出七个时间点

把一次变更拆成：源商品修改、前台发布、页面缓存刷新、Feed 生成完成、传输或抓取开始、GMC 处理完成、结账最终确认。为每个时间点记录值与时区。只要顺序不合理，就可能存在一个短窗口，让系统看到旧 Feed 配新页面或新 Feed 配旧页面。

然后识别事实源。价格、促销价、库存和预售状态分别由哪个系统拥有最终决定权？若同一事实能被主题、应用、Feed 规则和补充数据源同时覆盖，就必须规定优先级。自动商品更新可以降低部分风险，但它应作为安全网；主链路仍需及时、可解释。

最后检查失败模式：Feed 生成失败是否仍发布旧文件；抓取失败是否有告警；大批量更新是否跨越多个缓存周期；促销结束后是否残留覆盖规则；缺货时页面是否仍允许购买。具体自动更新、可用状态和促销字段要求以当前官方资料为准。

先用 Feed 与网站一致性框架 检查横向证据，再用 Feed 增量更新 Playbook 设计分批、回滚与更新验证。

常见误判

• “现在前台是对的，之前的报错就不用管。”需要解释异常为何发生，否则下一次更新仍会复现。
• “提高抓取频率就能解决。”源文件生成慢、缓存未刷新或规则错误时，更频繁只会更快抓到错误。
• “自动修正已经覆盖，主 Feed 不改也行。”长期依赖覆盖会让数据源与页面真相分裂。
• “促销价和原价只要有一个对就行。”不同系统需要明确区分基础价格、有效促销及时间范围。
• “库存只有有货和没货。”预售、延期交付等状态必须与真实购买能力和页面承诺一致。

验证清单

• 为异常商品保存源数据、最终 Feed、已处理值、页面与结账证据。
• 记录所有时间点、时区、缓存策略、抓取计划和处理完成时间。
• 检查地区、币种、税费、会员价和折扣码是否改变最终价格。
• 检查父子变体是否误用同一价格或库存。
• 验证生成失败、抓取失败和大比例变更是否有告警与保护。
• 修复后至少走完一个完整更新周期并重新抽样，不只手工触发一次。
• 对字段允许值、自动更新行为、促销规则和政策风险按当前官方资料复核。

目录与页面对齐后，还要用Cart 与 Checkout 证据验收剧本确认最终交易价格和库存没有在购买路径里再次变化。

适用边界

本文适合价格、促销、库存和购买状态不一致的系统诊断，不提供特定平台插件配置。税费、分期、订阅、单位定价、预售等特殊模式可能需要额外规则。若异常由爬虫无法访问、恶意代码、账户限制或支付能力造成，应转入站点与合规诊断；若只是报表延迟，也应先验证数据口径，不把展示延迟误判成商品事实错误。