构建自定义Elasticsearch查询时正则处理应放在前端还是后端？

优先选择「前端仅上传原始用户输入，后端完成逻辑运算符识别、检索词解析、Elasticsearch查询体构建」的方案，前端解析构建查询体的方案没有实际性能收益，反而会带来大量不可控问题。

核心原因说明 #

• 不存在所谓的前端解析性能优势
  正则匹配逻辑运算符、拼接查询结构的算力开销在微秒级，远低于网络请求、Elasticsearch查询的毫秒级耗时，无论放在前后端都不会成为性能瓶颈。反而前端解析需要兼容不同浏览器、不同端侧的JS引擎正则实现差异，容易出现兼容问题导致的性能波动，得不偿失。
• 前端直接构建查询体存在致命安全风险
  一旦后端接收前端拼好的ES查询体直接转发给ES集群，等于把查询控制权完全交给客户端。恶意用户可以轻易绕过前端解析逻辑，构造注入查询遍历敏感字段、拉取全量数据、发起复杂度极高的嵌套查询打垮服务，后端如果要对传入的查询体做全量安全校验，开发成本远高于直接在后端解析原始输入。
• 前端实现会大幅提升维护成本
  搜索语法规则会持续迭代，比如后续新增NOT逻辑、括号优先级、精确匹配、字段限定检索等能力，如果解析逻辑放在前端，每次规则调整都需要重新发版，还要处理用户端缓存旧版本导致的新旧规则兼容问题；逻辑放在后端的话可以随时迭代上线，全量用户即时生效，不需要考虑端侧版本问题。
• 前端实现无法保证多端逻辑一致性
  如果后续需要适配移动端、小程序、开放API等多场景，前端解析方案需要在每个端重复实现一套完全相同的解析逻辑，稍有偏差就会出现「同一搜索词不同端返回结果不一致」的问题，后端统一处理可以保证所有入口走同一套解析逻辑，完全避免一致性问题。
• 前端生成查询条件存在准确性问题
  示例代码中时间范围计算依赖new Date()取客户端本地时间，一旦用户设备时钟不准、手动修改了系统时间，生成的时间过滤条件会完全错误，后端基于服务端统一时钟生成这类动态条件，结果才是可控的。

可选优化方案 #

如果想降低用户输入后的等待延迟，可以在前端做轻量的输入辅助能力，比如识别到And/Or等运算符时做语法高亮、给出输入提示、实时校验语法格式，但核心的解析、查询构建逻辑必须收敛在后端。

提到的前端构建查询体的参考实现如下，这类实现仅适合本地Demo场景，绝对不要用到生产环境：

body: {
      query: 
        buildQueryAnd(
          { match: { some_field: "someData" } },
          { range: { "@timestamp": { "gte": addMinutes(new Date(), -600000), "lt": new Date(), format: "strict_date_optional_time" } } },
        ),
      _source: buildSource("someField1","someField2",...),
      sort: [
        {
          "@timestamp": {
            order: "desc"
          }
        }
      ], 
      size: 50
    }

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