我会先交代项目背景和选型结论。从分词、词项字典和文档列表理解全文检索。倒排索引建立“词项到文档”的映射。查询时先找到词项，再读取包含该词项的文档列表，因此适合全文搜索，而不需要逐条扫描原始文本。

具体落地时，我会沿着实际调用链来讲。沿着「文档字段进入 Analyzer → 生成规范化 Term → 写入倒排词典与 Postings → 查询解析得到 Term → 求交并评分返回文档」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 文档字段进入 Analyzer 文本按字符过滤、Tokenizer 和 Token Filter 分析，索引与查询分析器不一致会导致看似存在却搜不到。 org.apache.lucene.index：Terms/Postings/Segment。 analyze/termvectors：Token 与词项证据。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

参数和容量不能靠默认值，我会结合业务量来定。对同一语料比较 keyword、中文 Analyzer 和 ngram 的词项数、召回与索引体积。

效果要用数据证明，线上问题也要能闭环。固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「零结果率」为主基线，记录值应满足「记录稳态基线」；同时保存 分析后 token 列表、Term 命中 docfreq，使后续变化能够回到同一时间轴比较。 字段使用 keyword 映射，索引中只有完整标题一个 Term，match 查询分析出的单词无法命中。改为 text 用于全文检索、keyword 子字段用于聚合排序后语义才分离。 索引与查询分词器不一致：分析后 token 列表：固定索引/查询 Analyzer。

最后我会主动说明这个方案不适合什么场景。方案：更适合的场景：主要收益：代价与边界。 text + Analyzer：全文检索、相关性和短语：支持分词与评分：聚合排序需额外 keyword 子字段。 keyword：精确过滤、聚合和排序：Term 稳定、doc values 友好：不做全文分词。 searchasyoutype/edge ngram：前缀联想：低延迟候选召回：索引体积和写入成本增加。