运营在后台点了上架，商品状态显示"出售中"，客户那边却说搜不到。这种问题看着玄，其实按四层往下查，基本上都能定位：数据层、索引层、展示层、缓存层。
先看数据层。很多商城后台的"上架"只是其中一个开关，实际还有好几个条件同时在管这个商品：是否审核通过、是否可售、上架时间是不是设成了未来某个时间点、所属店铺或分类有没有被隐藏。尤其"定时上架"这个功能，页面显示已上架，但生效时间还没到，前台就是不出来，而列表页又不显示这个字段，非常容易看漏。
再看库存。主商品显示有货，但下面几个规格（SKU）的库存全是 0，前台会把这个商品判成不可售，搜索和列表里直接过滤掉。很多人只看了商品总库存，没点进规格明细，白找半小时。
接着看分类和标签。商品没挂到任何前台可见的分类下，或者挂的分类本身被设成隐藏、只对特定会员组可见，那它在分类页里就不可能出现。有些系统还支持"区域限售"，商品对一个配送区域外的用户直接不可见，测试的时候如果用外地 IP，看到的自然是空的。
然后是索引层，这一层最容易被忽略。商城搜索多数不走数据库直接查，而是把商品数据同步到独立的搜索引擎里，改了商品要等同步任务跑完才生效。判断方法很干脆：用商品详情页的直链能不能打开？能打开说明数据没问题；分类页里有没有？有而搜索没有，就是索引没更新。这时手动触发一次重建索引，或者等下一次定时任务，通常几分钟就恢复。
最后是缓存。商品缓存、分类缓存、首页缓存、CDN 的页面缓存，任何一层没刷，前台看到的都是旧数据。测试的时候一定要用无痕窗口，或者换一个没登录过的浏览器——用自己天天访问的浏览器测，很可能测的是缓存里的旧页面，然后得出错误结论。
还有一种情况不在系统这边：客户自己在结果页勾了筛选条件，比如"仅看有货""50 元以下""支持次日达"，或者他登录的是另一个会员等级，看到的价格区间和商品范围本来就不一样。让客户清掉筛选、退出登录再看一次，能排掉相当一部分"搜不到"的报障。
顺便说一句多端的问题。小程序、H5、PC 三端有时跑的不是同一套接口，缓存策略也不同，会出现"电脑上能搜到、小程序搜不到"。报障时先问清是哪一端、什么版本，比盲目排查省时间。
想以后少出这种事，上架后做一次自检就够了：无痕窗口搜一次商品名、点进分类翻一页、加一次购物车、走到结算页看价格对不对，全程不到两分钟。系统层面再配一个"上架后自动触发索引更新"，并且避免直接改数据库来上下架商品，绕过业务逻辑改出来的数据，往往缺字段、不同步，后患比省下的那点时间多得多。