SegmentTermsEnum 和 IntersectTermsEnum 的核心区别
SegmentTermsEnum和IntersectTermsEnum的核心区别确实在next()方法（以及相关的 seek 方法）上，而一旦某个 term 被定位到（无论通过哪种方式），后续获取其倒排列表（postings）的过程就是完全一致的。
🔍 详细对比：next()方法的行为差异
| 特性 | SegmentTermsEnum#next() | IntersectTermsEnum#next() |
|---|---|---|
| 目标 | 按字典序返回下一个 term | 返回下一个匹配自动机（Automaton）的 term |
| 遍历结构 | 基于.tim文件中的BlockTree（前缀树 + block 列表） | 基于字段的FST（有限状态转换器） + Automaton 交集运算 |
| 是否跳过 term | ❌ 不跳过，顺序遍历所有 term | ✅ 跳过不匹配自动机的 term |
| 底层机制 | 在 BlockTree 中逐层展开 block，读取 suffixes | 使用Automaton驱动 FST 遍历，只跟进接受路径 |
| 性能特点 | 全量扫描 O(N) | 只访问匹配路径，可能大幅跳过无关 term |
🧠 举个例子
假设字段中有以下 terms（已排序）：
apple, application, apply, banana, band, catSegmentTermsEnum.next()会依次返回：apple → application → apply → banana → band → cat如果你用一个自动机匹配以
"app"开头的词（如正则app.*），IntersectTermsEnum.next()只会返回：apple → application → apply并在
apply之后返回null（即使后面还有banana等）。
但当你调用
postings()时，无论是apple（来自哪个 enum），Lucene 都用同样的方式去.doc文件里读它的文档列表。
📌 关键设计思想：关注点分离（Separation of Concerns）
- Term 枚举逻辑（怎么找下一个 term）→ 由
next()/seekCeil()等方法实现，因用途而异 - Postings 读取逻辑（找到 term 后怎么读文档列表）→ 由
postings()实现，与枚举方式无关
因此，postings()方法可以安全地复用，无需重复实现。
✅ 总结
是的，区别主要就在
next()（以及seekExact,seekCeil等）方法上。
SegmentTermsEnum：全量、有序遍历IntersectTermsEnum：按自动机规则过滤遍历一旦 term 被定位，二者在数据读取层面完全一致，所以
postings()实现相同是合理且高效的设计。