Solr 8.8.1基于eDisMax与EdgeNGramFilter的部分词匹配无结果问题

• 核心错误是索引端分析链的过滤器顺序配置颠倒，导致实际生成的索引token和预期完全不一致。
• 原配置下，文档中的longer经过索引端处理的完整流程为：
  1. 标准分词器切出原始token longer
  2. 依次经过停用词过滤、小写转换、所有格过滤，token仍为longer
  3. 先执行PorterStemFilterFactory，按照英文词干规则将longer转换为词干形式long
  4. 最后执行EdgeNGramFilterFactory，基于已被改写的long生成长度为3的lon、长度为4的long两个token
• 这也是两类查询结果出现差异的原因：
  • 查alltext_en:longer能命中：查询端的Porter词干过滤会同样将输入的longer转换为long，和索引里存储的long token完美匹配
  • 查alltext_en:longe无结果：longe属于非通用英文词汇，Porter词干算法不会对其做任何改写，查询端最终输出的token就是longe，但索引中根本不存在对应token，因此explain直接返回No matching clauses

1. 调整managed-schema中text_en类型的索引端分析链顺序，将EdgeNGramFilterFactory挪到PorterStemFilterFactory之前，调整后索引端过滤器顺序为：
   • 标准分词器
   • 英文停用词过滤
   • 小写转换
   • 英文所有格过滤
   • EdgeNGram前缀生成（保留原有minGramSize=3、maxGramSize=15配置）
   • Porter词干过滤
     调整后，原始词longer会先被拆分为lon、long、longe、longer全量前缀片段，再对每个片段做词干处理，完全符合预期的分词结果。
2. 删除现有全量索引，按照新的schema配置重新导入文档。原索引的token是基于错误流程生成的，仅修改配置不重建索引，无法实现预期的匹配效果。
3. 校验查询端分析链：调整配置后输入longe做测试，如果发现Porter词干过滤会对输入的部分片段做非预期改写，可直接移除查询端的PorterStemFilterFactory，保证查询端输出的token和索引端生成的n-gram token完全对齐。

进入Solr内置的Schema分析工具，选择text_en字段，分别在索引分析栏输入longer、查询分析栏输入longe，逐环节核对两边输出的token是否存在交集，确认匹配逻辑正常后再做全量检索测试。

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