商品搜索和筛选索引要先服务业务路径

商品列表一旦开始承载搜索、分类、品牌、价格区间和上下架状态，索引策略就会马上变成瓶颈。很多系统前期会本能地给几个常用字段都加索引，但到了真实查询组合场景里，效果常常并不理想。

我更在意的不是“字段有没有索引”，而是高频业务路径是不是被索引结构认真照顾过。比如移动端首页推荐、后台商品管理、活动页筛选，它们的查询模式其实差很多。Feathers 服务层最好先把这些典型查询抽出来，再回头看 Sequelize 对应的 where、order 和分页是否真的命中索引。

如果索引策略只按表结构来想，很容易出现单字段索引很多、组合查询还是慢的情况。再往后发展，团队就会不自觉地去加缓存掩盖问题，而不是先把数据库路径理顺。

商品搜索体验最终还是落在用户可见的响应速度上。索引应该服务业务路径，而不是服务我们对数据库“看起来很完整”的想象。

电商链路里最怕的是边界看起来清楚，状态其实在串味

「商品搜索和筛选索引要先服务业务路径」这种问题在电商系统里几乎都会反复出现，因为订单、购物车、支付、搜索这些模块在业务上彼此相关，但在数据职责上又必须保持克制。前期如果为了开发快而把查询、状态流和补偿动作揉在一起，后面最先受伤的通常不是单个接口，而是排障和补单流程。

落地时优先守住的线

• 先定义谁拥有状态迁移，谁只消费结果，别让多个服务都觉得自己可以改同一份关键状态。
• 把幂等键、事件表和补偿动作放在入口附近，避免重复回调或重复消息把下游一起带乱。
• 搜索、筛选和列表接口优先服务真实业务路径，而不是为了复用表结构把所有能力硬塞进一条查询。