同一个 SKU 能在搜索结果中找到，却不出现在所属分类；或者分类显示 120 件，搜索同一关键词只有 113 件。两种页面看起来都是“商品列表”，但候选商品来源和过滤条件并不完全相同。简单清缓存可能暂时改变结果，却无法说明是哪一层不一致。

先选三个具体 SKU 做集合差异

不要从总数开始猜。分别找“只在搜索出现”“只在分类出现”“两边都有但排序异常”的 SKU，记录 store view、客户组、库存地点、币种和登录状态。总数还可能受分页、聚合和近似计数影响，具体实体更容易追踪。

分类页先看关联与网站范围

SELECT cp.category_id, cp.product_id, cp.position
FROM catalog_category_product AS cp
JOIN catalog_product_entity AS p ON p.entity_id = cp.product_id
WHERE p.sku = 'SKU-001';

有关系行还不够。分类与商品都必须分配到当前 website/store，商品状态启用，visibility 允许出现在 catalog。可配置商品还要看父商品状态与至少一个可售子商品。后台“选择了分类”但导入后索引未更新，也会出现关系存在、前台缺失。

搜索读的是搜索引擎文档

Magento 2 的目录搜索会把商品字段写入 OpenSearch/Elasticsearch 索引。文档可能仍保留已经删除的分类或旧状态，也可能因为批量索引失败而缺少新商品。先看 indexer 状态与 backlog：

bin/magento indexer:status
bin/magento indexer:show-mode
bin/magento indexer:reindex catalogsearch_fulltext catalog_category_product
bin/magento cron:run --group=index

全量重建只能作为诊断和一次性恢复。若重建后两边一致，随后又分叉，应检查 mview_state、changelog 消费、Cron 和导入程序是否触发变更。不要安排每五分钟全量重建来掩盖增量链路故障。

可见性条件本来就不同

商品 visibility 可以是 Not Visible Individually、Catalog、Search、Catalog/Search。设为 Search 的商品可以在搜索出现而分类页隐藏；设为 Catalog 则相反。这是配置行为，不是索引错误。先在正确 store scope 查看 visibility，因为默认范围与 store override 可能不同。

库存与价格会进一步过滤

开启隐藏缺货商品后，库存可售性会影响集合。MSI 环境下不要只查 legacy stock item 的 qty，应确认当前 sales channel 对应 stock、source item 状态、reservation 和 salable quantity。客户组权限、共享目录、价格为零的自定义过滤也可能只挂在某一种列表 provider 上。

若主题或扩展对分类 collection 加了额外 plugin，例如排除无图片商品，而搜索 adapter 没有同样规则，两边永远不会一致。搜索代码时查 collection processor、layer、search criteria 与 around plugin，不要只查模板。

URL 参数会悄悄改变集合

分类页可能保留 ?color=、price、mode、order 参数；搜索页有 query text、同义词、最小匹配和拼写修正。测试时从干净 URL 开始，清空 localStorage 中的自定义筛选状态。Canonical 是否去掉参数只影响搜索引擎理解，不会替你修复运行时集合。

正确的验证方式

对三个样本 SKU 逐层记录：数据库分类关联、store 级状态与可见性、website 分配、当前 stock 可售性、搜索文档是否存在、最终查询是否包含。修复后修改其中一个商品的分类与状态，等待增量索引，再看两页是否同步变化。只有增量路径通过，才能说明两套数据重新对齐。