为什么 Adobe Commerce 的 Live Search 会显示您已经没有的商品

顾客在您的店铺里搜索，找到一件商品，点进去却发现已经缺货；或者搜索结果页上的价格还是上周的。后台的商品目录是对的，商品数据也是对的，只有搜索结果是错的。

我们在写Live Search 与 AI 推荐究竟带来了什么时曾顺带提过这件事：在那几个项目里，让 Live Search 的商品数据保持准确同步，需要相当的集成工作，尤其是在库存与价格不断变动的目录上。这是数据管道的问题，不是 AI 的问题，值得单独讲清楚。

Live Search 并不读取您的数据库

这是多数团队最容易忽略的一点，后面的一切都由此而来。

Live Search 是一项 SaaS 服务。顾客在搜索框里输入时，前台并不是去查询您自己的 MySQL 商品目录，而是去查询 Adobe 的服务；而这项服务用来作答的，是您的店铺此前导出给它的一份目录副本。维护这份副本的，是 SaaS Data Export 扩展（在新标签页中打开）。

因此，「后台里这件商品是对的」和「搜索结果里这件商品是对的」是两个不同的判断。前者说的是您的数据库正确，后者说的是导出管道已经把这次修正送达了，而这两者之间可以相差好几天，期间看不出任何异常。

一次商品改动是如何抵达搜索索引的

Adobe 把这个流程记录（在新标签页中打开）为一条链条。值得了解，因为链条上任何一环出问题，表现出来的症状都一样：

1. 变更检测。 Mview 在 catalog_product_entity 一类的表中发现被修改的行，并写入变更日志。
2. 馈送索引。 馈送索引器读取变更日志，组装出馈送条目。
3. 采集。 各提供程序按每个馈送的结构收集字段数据。
4. 哈希去重。 内容哈希判断哪些确实变了，未改动的数据会被跳过而不重发。
5. 提交。 数据分批 POST 到 Adobe 的 Feed Ingestion Service。
6. 状态回写。 响应逐条更新馈送表。
7. 重试。 失败的条目按计划重新提交。

这里没有一步是即时的，而且全部依赖 cron：

Adobe 自己给出的说法是：商品更新应当在数分钟内完成索引，增量更新可能需要 15 到 20 分钟，而安装后的首次索引可能超过 30 分钟。如果 cron 状态不佳，或者变更日志堵在一次大规模目录操作后面，上面这些数字就都不成立。

那个会悄悄停掉更新的设置

这是整件事里最锋利的一处。持续发生的改动是通过部分同步送到服务端的，而部分同步只有在 cron 已启用、并且索引器处于 Update by Schedule 模式时才会运行。

把某个索引器改回 Update on Save，馈送索引器就没有变更日志可读了。不会报错。后台看起来一切正常。您的商品目录只是不再抵达 Live Search，而最终告诉您这件事的是顾客。

这一点与2.4.8 升级直接相关：Adobe 已把新装与升级时的默认索引器模式从 Update on Save 改为 Update by Schedule。这个默认值如今站在您这一边。但它保护不了这样一种店铺：有人在排查别的问题时把索引器切回了 Update on Save，然后再也没有切回来。

「已提交」并不等于「已生效」

后台对此有一个真正可用的答案，位置在 System > Data Transfer > Data Feed Sync Status。它按馈送显示四种状态：

它还会显示待同步记录数与已发送记录数的对比、变更日志的积压量，以及每个索引器处于哪种模式，而这正是抓住上一节那个问题最快的办法。

Adobe 文档里有一句提醒值得原样记住，因为它决定了这件事是花五分钟核对还是花两天翻查：导出成功并不保证数据已经在下游的连接服务中可用。Submitted to service只表示您的店铺把数据交出去了，并不表示搜索索引已经把它吸收完毕。

找出出错的那一个 SKU

当出问题的是个别商品而不是整个目录时，问题就变成了：是链条上的哪一环把它漏掉了。Adobe 的排查文章（在新标签页中打开）直接从馈送表入手，并给出了可以照抄的查询语句。

在 cde_products_feed 中按该 SKU 查询，用 feed_data 这个 JSON 里的 sku 与 storeViewCode 值来匹配。如果查不到行，说明这次改动根本没有变成馈送条目，问题出在更上游的变更检测或馈送索引环节。如果行在但内容陈旧，就把它的 modified_at 和商品自身的修改时间做对比，再到 scopes_website_data_exporter 里查最后一次导出的时间戳。仅这一次对比，就能把「我们根本没采集到」和「采集了但没发出去」分开，这是两种不同的故障，处理方式也不同。商品属性另有一个馈送表 cde_product_attributes_feed，当商品在、但某个字段不对时，值得单独查一下它。

需要手动推动管道时：

• bin/magento cron:run --group=saas_data_exporter 立即触发一次同步
• bin/magento indexer:reindex cde_products_feed 重建商品馈送
• bin/magento saas:resync --feed products 重发新增、更新以及此前失败的条目

请谨慎对待 --cleanup-feed。 它出现在 Adobe 关于 Data Space ID 变更后如何恢复的说明里，而 Adobe 明确指出它用于整套环境重建，而不是日常排查。它不是那种「重新同步一次没成功，就再加上去」的参数。

为什么库存与价格频繁变动才是难点

一天只变两次的目录，几乎不受上述任何一点影响。商品编辑晚 15 分钟生效，没人看得出来。

难点出现在库存与价格持续变动的时候，而这正是那些在做促销、有市场平台渠道、或者 ERP 整天推送更新的零售商的常态。这时变更日志就没有安静的时候，导出始终在工作，导出副本与商品目录不一致的那个窗口，也就从偶尔出现变成了长期敞开。

这也是为什么这件事常常最终并不是搜索的问题。如果库存数字本身就是从上游的 ERP 或 POS迟到地进入商品目录的，那么 Live Search 只是忠实地导出了它收到时就已经错了的数字。管道对着错误的输入做了正确的事。明明故障在上游两跳之外的系统，却从搜索索引开始查，是在这个问题上损失一周的最常见方式。

对于库存确实同时分布在多个地方——网店、市场平台、实体门店——的零售商来说，根本的解法不是把某一条导出调得更紧，而是让商品、价格与库存拥有单一的可信来源。这正是 WOW Sync 存在的意义，它位于本文所述一切的上游。

如果您的 Live Search 结果与商品目录对不上，又不想花一周去查原因，欢迎与我们联系。

---

资料来源：Adobe Experience League 的 SaaS Data Export 指南（在新标签页中打开）、使用 SaaS Data Export 同步数据（在新标签页中打开）、Data Feed Sync Status（在新标签页中打开） 与 Live Search 商品目录未同步（在新标签页中打开），以及我们自己在 Adobe Commerce 商品目录上的集成经验。