基于多关键词筛选的REST API设计与Spring后端实现咨询

你提到的"根据用户选中关键词动态构造查询逻辑"的方向完全合理，和当前本地化搜索、多条件筛选类REST API的主流设计逻辑一致，核心要规避的是直接拼接原生SQL字符串带来的注入风险与长期维护成本，不需要完全推翻这个思路。

• 先做入参的标准化收敛
  绝对不要把前端传递的关键词字符串直接透传到查询层，提前在后端定义统一的过滤关键词枚举，把前端传值和后端内部逻辑做强映射：

  // 统一的搜索过滤关键词枚举，和前端入参值一一绑定
  public enum SearchFilterEnum {
      OPEN_NOW("open_now"),
      TOP_RATED("top_rated"),
      NEW("newest");
      // 枚举属性、构造方法、getter省略
  }
  

  接口接收到请求后，先对入参的关键词列表做校验，不在枚举白名单范围内的非法值直接返回参数错误，从入口层切断SQL注入的可能。

• 用框架原生能力实现动态查询，杜绝手写SQL拼接
  没必要自己手写字符串拼SQL，Spring生态已经有成熟的动态条件构造能力可以直接复用：

  • 如果用Spring Data JPA：基于Specification接口为每个枚举绑定独立的过滤逻辑，比如OPEN_NOW对应的过滤条件是"当前时间匹配门店营业时间"，TOP_RATED对应的过滤条件是"门店评分高于预设阈值"。请求进来后把所有用户选中关键词对应的过滤条件用AND逻辑拼接，传入查询方法即可。
  • 如果用MyBatis/MyBatis-Plus：基于QueryWrapper条件构造器实现和上面完全一致的逻辑，每个枚举对应独立的条件片段，动态组装查询规则，所有参数走预编译流程，天然规避注入风险。

• 动态适配结果排序规则
  参考同类产品的实际体验，不要把排序逻辑写死：每个关键词除了对应过滤条件，还要绑定对应的排序权重。比如用户同时选中"open now"和"top rated"时，查询完成后按照"评分优先、距离其次"的规则排序；用户选中"new"时，把门店创建时间的权重提升到最高，保证返回结果完全匹配用户的筛选预期。

• 不要把关键词对应的过滤逻辑散落在各个业务代码块里，所有和关键词绑定的判断规则要统一封装在对应的枚举实现内。后续调整规则（比如优化营业状态的判断逻辑、调整高评分的阈值）时，只需要修改单处代码即可，避免全项目散改的高昂维护成本。
• 不要为了所谓的灵活性开放自定义查询字段，所有支持的筛选关键词要做严格的白名单管理，超出白名单的请求直接拦截，避免给数据库带来不必要的全表扫描压力。
• 预留查询引擎的扩展能力：当后续数据量增长、现有关系型数据库查询性能无法支撑时，只要把枚举对应的查询逻辑从SQL实现替换为搜索引擎的查询DSL即可，上层的接口入参、枚举定义完全不需要改动，大幅降低架构迁移的成本。

内容的提问来源于stack exchange，提问作者hinewwiner