如何判断Compass(Lucene)索引是否配置等价Lucene Field.Store.NO的字段存储

两类疑惑配置的实际作用边界 #

你看到的两类配置和字段存储完全无关，各自的作用可以通过配置命名规则、自定义分析器的源码逻辑100%明确：

• PerFieldConfig-stopwords-* 开头的配置项里的value="no:"，仅代表不对该字段应用停用词过滤规则，绝非不存储字段内容
  源码逻辑里遇到以no:开头的停用词配置时，会直接把该字段的停用词集合设置为空数组，分词过程中不会过滤任何词，整个处理流程完全服务于分词环节，没有任何和存储相关的逻辑分支。
  同结构的yes:词1,词2配置，会把冒号后的逗号分隔词列表设置为该字段专属的停用词集合；如果不配置这类项，就使用对应分词器自带的默认停用词规则。
• 以PerField-*开头、值为分词器全类名的配置（比如value="org.apache.lucene.analysis.standard.StandardAnalyzer"），仅代表为对应字段指定分词处理逻辑，和字段是否存储没有任何关联
  不管配置成标准分析器、关键字分析器还是其他分词器，都不会改变字段的存储行为：标准分析器只是做常规的分词切分，关键字分析器只是把整个字段值当成一个完整词条处理，两类分词器的配置本身都不涉及存储控制。

字段存储规则的真正控制位置 #

不管是Compass框架还是底层的原生Lucene，字段的存储选项（对应Lucene的Field.Store.YES/NO）从来不会在全局分析器配置、引擎全局配置里定义，全部由映射类的字段级配置决定——也就是你配置里引入的myclass.tserver.beans.search.SearchIndex类中，每个业务字段标注的Compass映射注解，才是决定字段是否存储的核心：

• 如果字段注解标记为不存储原始值，建索引时就只会生成倒排索引用于匹配，不会把字段原始值写入索引的存储段
• 如果字段注解标记为存储原始值，建索引时会把字段原始值写入存储段，后续从索引查询时可以直接返回字段值，不需要回查数据库

从自定义分析器的源码也能佐证这个边界：PerFieldAnalyzer的全部逻辑仅围绕“给不同字段挂载对应分词器、给分词器配置专属停用词集合”展开，没有任何一处代码会修改Lucene文档构建阶段的字段存储选项，完全不可能干预存储行为。

现有观察结果的推导结论 #

你之前用Luke.net打开索引，观察到“仅能取到id字段值、看不到其他业务字段的存储内容”，已经可以直接证明这套Compass应用的字段配置，本质等价于Lucene.NET的Field.Store.NO规则：

• 只有当所有业务字段都被配置为不存储原始值、仅主键id字段配置为存储原始值时，Luke打开索引才会呈现“仅返回id、其余字段无存储值，需要靠id回查数据库”的表现
• 这套索引的设计思路就是用倒排索引做匹配召回，拿到匹配结果的id后再回业务数据库查询完整数据，和初步推测的逻辑完全一致。

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