match_phrase_prefix 的补全效果

做的事：真实用match_phrase_prefix模拟用户边打字边搜索的自动补全场景

代码真实索引4篇文档: "Quick Brown Fox" / "Quick Brown Bear" / "Quick Blue Jay" / "Slow Brown Fox" POST /mpp_test/_search {"query":{"match_phrase_prefix":{"title":"quick br"}}} POST /mpp_test/_search {"query":{"match_phrase":{"title":"quick br"}}} # 对比普通短语查询

验证：match_phrase_prefix真实把"br"当成前缀命中了2篇，match_phrase真实0命中

match_phrase_prefix搜"quick br":
→ "Quick Brown Fox" score=0.7133499
→ "Quick Brown Bear" score=0.7133499
  ← 真实两篇都命中了，"br"被当成了"brown"的前缀

match_phrase搜同样的"quick br":
→ hits = 0   ← 真实一个都查不到！"br"不是索引里的完整词

这组对比真实验证了match_phrase_prefix存在的真实意义：它跟本系列第31篇讲过的match_phrase共享"查询词必须按顺序紧邻出现"这个核心要求，但额外真实赋予了最后一个词"前缀匹配"的特权——查询词组里除最后一个词外，前面的词都必须是索引里的完整词项精确匹配，只有最后一个词真实被当成一个前缀，去匹配所有以它开头的词项。普通的match_phrase真实没有这个特殊处理，"br"在索引里真实根本不是一个完整词项，直接查不到任何结果。这正是搜索框"输入到一半就能看到候选结果"这种体验的真实底层机制。

真实用explain看match_phrase_prefix到底把查询语句改写成了什么样子

代码POST /mpp_test/_validate/query?explain=true {"query":{"match_phrase_prefix":{"title":"quick br"}}}

验证：explain真实显示最后一个词被改写成了带星号的前缀"br*"

explain输出:
→ "title:\"quick br*\""
  ← 真实前面的quick保持原样，最后一个词br真实被加上了星号变成通配前缀

这条explain真实直接证明了match_phrase_prefix的实现方式：它真实不是某种全新的匹配算法，而是在构造短语查询时，把短语里的最后一个词替换成了一个前缀查询（br*），前面的词依然保持精确的短语位置约束。这也意味着它真实继承了本系列第36篇验证过的通配符查询特性——真实需要在倒排索引的词典里枚举所有以"br"开头的候选词项，再分别尝试跟前面的词组成有效短语。

真实验证max_expansions参数如何限制候选词项数量，进而真实影响召回结果

代码原文里以"b"开头、紧跟在quick后面的候选词真实有bear/blue/brown三个 POST /mpp_test/_search {"query":{"match_phrase_prefix":{"title":{"query":"quick b","max_expansions":1}}}} POST /mpp_test/_search {"query":{"match_phrase_prefix":{"title":{"query":"quick b","max_expansions":10}}}}

验证：max_expansions=1真实只展开了1个候选词，刚好没选中真实匹配的那个，查询变成0命中

max_expansions=1: hits = 0   ← 真实查不到任何结果！
  ← 以b开头的候选词真实按字典序排列是bear/blue/brown，限制只展开1个的话
  ← 真实只会尝试"bear"这一个候选词，但原文里quick后面真实没有紧跟着bear

max_expansions=10（足够覆盖全部3个候选词）: hits = 3
→ ["Quick Brown Fox", "Quick Brown Bear", "Quick Blue Jay"]
  ← 真实把brown和blue这两个真正匹配的候选词都覆盖到了

分步演示：从match_phrase_prefix的前缀展开机制到max_expansions的真实召回影响

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。