这是个非常务实的同义词索引设计问题，咱们来拆解两种方案的优劣，再结合你的需求给出最优实践方向。

方案一：Keyword类型存储多值同义词 #

你提到的第一种方案是用keyword类型字段，手动把所有同义词/变体都塞进数组里，示例如下：

// 索引配置
{ 
  "mappings": {
    "properties": {
      "keywordField": { "type": "keyword" }
    }
  }
}

// 文档内容
{ "keywordField": ["leagueoflegends", "league", "legends", "lol"] }

优点 #

• 匹配绝对精准：keyword类型是精确匹配，只要查询的词在数组里就能命中，不会出现分词带来的意外匹配。
• 实现门槛低：不需要配置复杂的分析器，直接把所有需要覆盖的关键词都存进去就行。

缺点 #

• 维护成本极高：以后要加新的同义词（比如新增“LoL”这类变体），必须逐个更新文档，把新词加到数组里，没法统一批量更新。
• 存储空间浪费：每个文档都要重复存储一堆同义词，尤其是当同义词数量多的时候，存储开销会明显增加。
• 大小写敏感问题：默认情况下keyword是大小写敏感的，如果用户搜League而你存的是league，就会匹配失败，还得额外配置normalizer来处理大小写转换，又多了一层复杂度。

方案二：Text类型+自定义同义词分析器 #

第二种方案是用text类型配合自定义分析器，把同义词逻辑交给Elasticsearch的分析链处理，这也是官方推荐的同义词实现方式。先补全你的完整配置：

{
  "settings": {
    "analysis": {
      "analyzer": {
        "lowercase_and_whitespace_and_synonym_analyzer": {
          "tokenizer": "whitespace",
          "filter": ["lowercase", "my_synonym_filter"]
        }
      },
      "filter": {
        "my_synonym_filter": {
          "type": "synonym",
          "synonyms": [
            "lol => leagueoflegends",
            "league of legends => leagueoflegends, league, legends"
          ]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "keywordField": {
        "type": "text",
        "analyzer": "lowercase_and_whitespace_and_synonym_analyzer",
        "search_analyzer": "lowercase_and_whitespace_and_synonym_analyzer"
      }
    }
  }
}

存储的文档只需要原始内容：

{ "keywordField": "league of legends" }

优点 #

• 维护超级省心：所有同义词都集中在分析器的过滤器配置里，以后要加新变体，只需要更新索引设置（关闭索引→更新→重新打开，或者用别名无缝切换），不用碰任何文档。
• 存储高效：只需要存原始的关键词内容，分词、同义词转换全由分析器在索引/查询时自动处理，不会浪费存储空间。
• 完全满足你的查询需求：
  • lowercase过滤器自动把查询的League of Legends转成小写，消除大小写差异；
  • 同义词过滤器把lol、league of legends都映射到你需要的token（leagueoflegends、league、legends），不管用户搜哪个变体都能命中；
  • 用_analyze API测试时，也能得到你期望的分词结果。
• 符合Elasticsearch设计理念：text类型就是为全文检索、同义词、分词这类场景设计的，官方更推荐用分析链来处理这类逻辑，而不是手动维护多值数组。

缺点 #

• 配置需要一点耐心：要理清分词器、过滤器的顺序（比如必须先转小写再处理同义词），还要用_analyze API反复测试，确保同义词转换符合预期。不过一旦配置好，后续几乎不用再动。

最终推荐：选方案二 #

方案二更适合你的长期需求，它解决了方案一的所有痛点，扩展性、维护性、存储效率都远高于方案一，而且完全能满足你要求的所有查询匹配规则。

如果你担心配置出错，可以先用_analyze API逐个测试分析器的效果：

GET /_analyze
{
  "analyzer": "lowercase_and_whitespace_and_synonym_analyzer",
  "text": ["lol", "League of Legends"]
}

确认返回的token是你期望的leagueoflegends、league、legends后，再正式创建索引。

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