在 Lucene 里，liveDocs（通常写作 `liveDocs`） 是一个非常轻量的只读位图（`Bits`），用来快速回答“当前索引段里哪些文档还活着（即未被删除）”。 未被逻辑删除
(可能存在逻辑上已删除，但物理上还在，这种文档在livedocs认为是已经删除的)
一句话理解：
> `liveDocs` 就是“未删除文档的身份证列表”，搜索时凡是位为 `1` 的 docID 就参与打分、返回；为 `0` 的直接跳过。
要点拆解：
1. 数据结构
- 类型：`org.apache.lucene.util.Bits`（位图）
- 长度 = 段内最大 docID + 1
- 每个 bit 对应一个 docID：`true` 表示存活，`false` 表示已逻辑删除。
2. 从哪来
- `LeafReader.getLiveDocs()` 返回。
- 底层由 `LiveDocsFormat` 从 `.liv` 文件读取（Lucene 8.x 默认是 `Lucene50LiveDocsFormat`）。
3. 用来干什么
- 搜索阶段：
`IndexSearcher` 把 `liveDocs` 作为 `acceptDocs` 参数传给 `scoreAll`，见源码：
```java
scorer.score(leafCollector, ctx.reader().getLiveDocs());
```
- 合并阶段：`IndexWriter` 根据 `liveDocs` 把已删除文档真正丢弃，生成新的干净段。
4. 不存“删除文档”
- 它只记录“谁还活着”，并不保存删除文档的原始内容或列表。
- 已删除文档的数据仍在段文件里，只是被位图屏蔽，直到下次段合并才被物理清除。
因此，当你看到
```java
Bits liveDocs = reader.getLiveDocs();
```
就把它当成一张“快速通行证”：搜索时只让通行证上打钩的文档通过即可。
也就是说livedocs存的是所有没删除的文档?
是的，可以这么理解：
`liveDocs` 这个 `Bits` 对象覆盖了整个段的所有 docID，其中值为 `true` 的位正好对应当前仍然存活（未删除）的文档。
换句话说，它不是“存文档”，而是用一个位图标记每个 docID 是否有效。
- 位图长度 = 段内最大 docID + 1
- 位为 1 → 该 docID 对应的文档未删除
- 位为 0 → 该 docID 对应的文档已删除（逻辑删除）
所以 `liveDocs` 并不是把“没删除的文档列表”存进去，而是用“位数组”告诉我们哪些 docID 仍然可用。