【电商项目】商品搜索开发复盘（1）：根据需求拆解搜索接口的设计逻辑

一、搜索功能整体实现思路

[1. 为什么不用MySQL，全程基于ES做搜索？](#1. 为什么不用MySQL，全程基于ES做搜索？)

[2. 整体核心逻辑：传参 → 处理 → 出参](#2. 整体核心逻辑：传参 → 处理 → 出参)

[1.1 传参（构造ES查询条件）](#1.1 传参（构造ES查询条件）)

[1.2 处理（执行ES搜索）](#1.2 处理（执行ES搜索）)

[1.3 出参（封装返回前端的完整数据）](#1.3 出参（封装返回前端的完整数据）)

二、核心代码流程总览

核心复盘小结

前言

搜索功能的编写比较复杂，首先搜索条件 繁多，有关键字、价格、品牌、规格等。其次返回的结果除了搜索到的商品 ，还要返回搜索面板 ，包含关键字对应的品牌、品类、规格等，还要将搜索条件回显回去，供前端操作。

本篇先对大体实现思路进行回顾，然后再细复盘每一处的实现。

我们要实现的样式可以参考京东的面板。

一、搜索功能整体实现思路

1. 为什么不用MySQL，全程基于ES做搜索？

MySQL（正排索引）++查词要翻所有文档++ ，只适合简单 CRUD。面对商品关键字分词、模糊检索、多条件筛选、数据聚合场景，性能极差、无法实现分词匹配。

而 Elasticsearch 基于倒排索引设计 ，它会++先拆词，再记"这个词在哪些文档里"++，专门适用于解决全文检索场景。因此项目将商品搜索单独抽离，基于ES实现。

2. 整体核心逻辑：传参 → 处理 → 出参

1.1 传参（构造ES查询条件）

关于传参就看一个：接收后是否需要处理。

前端传入的 GoodsSearchParam 是业务封装的JSON参数，ES无法直接识别使用。我们需要把前端可读的业务参数，转换成ES可识别的检索语法，适配ES的查询规则。

所以首先我们要把前端传过来的数据构造成ES搜索条件。

1.2 处理（执行ES搜索）

我们的处理就是实现商品的搜索。

ES实现商品搜索：通过注入 ElasticsearchTemplate 调用search方法，传入构造好的ES查询条件，指定映射实体GoodsES，即可完成ES数据查询。

1.3 出参（封装返回前端的完整数据）

这是整个接口的核心，也是区别于普通查询的关键。ES原始查询结果不能直接返回前端，需要二次封装，对应两个核心需求：

1、分页商品数据：将ES查询的原始数据，封装为Page分页对象，提供商品列表、总条数、页码等，用于前端渲染商品列表；

2、搜索聚合面板数据：遍历所有搜索结果，聚合去重品牌、品类、规格数据，生成筛选面板；同时回显用户的搜索参数，保证前端搜索条件不丢失。

二、核心代码流程总览

复制代码

// 搜索产品
@Override
public GoodsSearchResult search(GoodsSearchParam goodsSearchParam) {
  // 1.构造ES搜索条件
  // 2.搜索
  // 3.将查询结果封装为Page对象
  // 4.封装结果对象
  // 4.1 查询结果
  // 4.2 查询参数
  // 4.3 查询面板
  return null;
}

核心复盘小结

1、1、2步是内部查询过程，只负责和ES交互，无对外返回数据；

2、3、4步是最终出参核心，所有给前端展示的列表、分页、筛选框、参数回显，全部来自这两步，也是搜索功能的业务核心。