Lucene：搜索引擎内部的倒排索引

一个装了两千万篇文档的系统，你输入"量子纠缠"，两百毫秒之内屏幕上出现十条结果，还按相关度排好了序。

如果换成逐篇读过去——两千万篇文档、平均每篇几千字，那是几十 GB 的文本。哪怕全部装在内存里、每秒扫十几 GB，一次查询也要好几秒；落到磁盘上则是几分钟。这个数量级差距不是靠"服务器更快"补上的，它必须靠换一种数据组织方式。

Apache Lucene 就是那种组织方式的一份工业级实现。Doug Cutting 在 1999 年写下它，2001 年 9 月它成为 Apache Jakarta 家族的一员，2005 年 2 月升为 Apache 顶级项目。今天 Elasticsearch、OpenSearch、Apache Solr 全都跑在它上面——这些系统的分布式、REST 接口、聚合语法各不相同，但一旦请求落到某个分片上，接手的都是同一套 Lucene 索引结构。理解 Lucene，等于理解了这一整代搜索系统的物理层。

破除误解#

误解一：倒排索引就是一张"词 → 文档编号"的大哈希表。

哈希表这个直觉会让你对后面所有的行为判断失误。Lucene 的词项字典是严格按字节序排好序的，而不是哈希打散的——因为排序带来的能力是哈希给不了的：前缀查询（quan*）、范围查询（price:[100 TO 200]）、模糊查询（编辑距离）都依赖"相邻的词在物理上也相邻"。而且倒排表本身也不是一个数组，它是分块压缩、带多级跳表、块内还预存了最大得分的结构。把它想成哈希表，你就无法解释为什么 prefix 查询能跑、为什么 term 查询比 wildcard 快几个数量级。

误解二：可以像改数据库一行那样，更新文档里的某一个字段。

Lucene 的倒排字段不支持任何形式的原地修改。IndexWriter.updateDocument() 这个名字有误导性，它做的事是：把旧文档在一个位图里标记为"已删除"，然后把整篇新文档当作全新文档追加进去。Elasticsearch 的 _update API 同理——它先把 _source 整篇取回来，在内存里改掉一个字段，再把整篇重新索引一遍。所以"只改一个字段"在成本上等于"重写整篇文档"，这一点直接决定了它不适合做计数器。

误解三：删掉一半数据，磁盘占用就会掉一半；Elasticsearch 是实时的。

两句都不对。删除只是在段的 .liv 位图里把某一位置 0，被删文档的词项、倒排表、存储字段一个字节都没被清掉，它们只是在查询时被过滤掉。空间要等到这个段参与合并（merge）时才被真正回收，而合并什么时候发生由合并策略决定，可能是几分钟后，也可能永远不会。至于实时——Elasticsearch 默认每 1 秒做一次 refresh，写入到能被搜到之间有一个可见性窗口；官方的措辞一直是 near real-time（近实时），从来不是 real-time。

从扫描到查表：倒排索引的形状#

先把两种组织方式摆在一起。

正排（forward index）是文档的自然形态：文档号 → 它包含的词。

doc 7  → [量子, 纠缠, 贝尔, 不等式, 实验, ...]
doc 12 → [纠缠, 退相干, 环境, 噪声, ...]
```

倒排（inverted index）把这张表转置：词 → 包含它的文档号列表。

"纠缠"   → [7, 12, 40, 41, 43, 88, ...]
"贝尔"   → [7, 156, 902, ...]
"退相干" → [12, 340, ...]
```

转置之后，查询从"遍历所有文档、检查是否含某词"变成了"定位一个词、直接读它的列表"。代价从与文档总数成正比，降到与命中数成正比。一个两千万篇文档的索引里，某个中频词命中两万篇，读出来的压缩数据可能只有几十 KB——这就是几分钟和几毫秒的差别来源。

最后一行很关键：Lucene 同时维护这三种结构，它们各自服务不同的查询阶段——倒排索引负责"找出哪些文档匹配"，doc values 这一列式结构负责排序和聚合，stored fields 负责最后把原文取回来展示。很多人以为搜索引擎里只有倒排索引，于是无法解释为什么 Elasticsearch 做聚合时内存行为完全不同——因为那时候用的根本不是倒排索引。

还有一件必须说清的事：索引里存的不是原文，是分析（analysis）之后的词项。文本要先过一条分析链——分词、小写折叠、Unicode 规范化、去停用词、词干还原——出来的 token 才进倒排表。中文没有天然空格，Lucene 生态里常用的是二元切分（把"量子纠缠"切成"量子/子纠/纠缠"）或基于词典的分词器。这条链是写入时固化的：你改了分词器，已经写进去的文档不会跟着变，必须重建索引（reindex）。这就是为什么 Elasticsearch 里改 mapping 的 analyzer 一定要重建索引，而不是"重启一下生效"。

词项字典：为什么用 FST 而不是哈希表#

有了词，怎么快速找到它对应的倒排表位置？

Lucene 4.0（2012 年 10 月）把这一层重写为基于 FST（Finite State Transducer，有限状态转换器）的结构，一直沿用至今。FST 可以理解成一个"能输出值的字典树"：它把所有词项按字节序压进一张有向无环状态图，公共前缀共享路径，公共后缀也合并，走完一条路径不仅确认词存在，还能沿路累加出一个输出值——在 Lucene 里，这个输出值是该词项所在数据块在 .tim 文件里的偏移量。

落到文件上是两个：

• .tim（term dictionary）——真正的词项字典，按块存储，每块几十个共享前缀的词及其倒排表指针；
• .tip（term index）——常驻的 FST，它只索引块的前缀，不索引每个词。

这是一个刻意的取舍：.tip 只需要小到能整体驻留，就能把任意一个词定位到 .tim 里的一个块，然后顺序扫这一个块找到具体词项。用一次小范围顺序读，换掉一个巨大的全量索引——典型的"磁盘友好"设计。

Lucene 8.0（2019 年 3 月）进一步把非主键字段的词项索引 FST 通过 MMapDirectory 移到堆外，代价是词项查找略微变慢，收益是 JVM 堆压力大幅下降。这直接对应了 Elasticsearch 运维史上一个著名转折：7.x 之前"段越多、堆占用越高，段内存是节点的隐形天花板"，之后这个问题显著缓解。

而选择 FST 而不是哈希表的根本理由只有一个：有序性。前缀查询是在 FST 上走一段路径然后收集子树；范围查询是在有序字典上取一个区间；模糊查询是把编辑距离编译成一个自动机，与词项 FST 求交。哈希表把顺序打散了，这些能力全部消失。

倒排表的压缩：差分、位打包与跳表#

一个高频词的倒排表可能有几百万个文档号。如果每个都用 4 字节存，光是"的"这样的词就能吃掉十几 MB。Lucene 的压缩分三步。

第一步：差分编码。 文档号在倒排表里是递增有序的，于是只存相邻差值：

doc IDs : 3,  7,  9, 12, 40, 41, 43, 44, ...
deltas  : 3,  4,  2,  3, 28,  1,  2,  1, ...
```

词越常见，命中越密集，差值就越小——这是一个非常漂亮的自适应性质：越高频的词，每个文档的存储成本反而越低。

第二步：分块位打包。 Lucene 的倒排表格式（从 Lucene 4.1 的 Lucene41PostingsFormat 到 8.4 的 Lucene84PostingsFormat 及之后各版本，机制一脉相承）把差值切成每 128 个一块，同一块内所有整数用相同位宽存储，位宽取这一块里最大值所需的比特数。上面那段若在同一块内，最大差值 28 需要 5 比特，于是 128 个数各占 5 比特，而不是 32 比特——压缩比接近 6:1，且解码是纯粹的移位与掩码，可以做得极快。凑不满 128 个的尾巴用变长整数（VInt）逐个存。

第三步：跳表。 布尔查询要做倒排表求交（量子 AND 纠缠），核心操作是 advance(target)：跳到第一个不小于 target 的文档。差分编码有个副作用——你不能随机访问第 5000 个元素，因为必须从头累加。跳表（skip data）就是为了补这个洞：它随倒排表一起写在 .doc 文件里，按块记录"这一块结束时的文档号是多少、下一块从文件哪个偏移开始"，块之上再叠加更稀疏的层级（Lucene 的经典实现里每层稀疏 8 倍，最多十层左右）。只有文档频率达到一个块以上的词才值得建跳表，短表直接顺序扫更划算。

于是求交变成：拿两条倒排表里较短的那条驱动，每取一个文档号就在另一条上 advance，跳表让你整块整块地略过不可能匹配的区域，连解压都省了。这就是"倒排表必须有序"这个约定的全部回报——差分、跳表、流式求交，三件事都建立在它之上。

代价也在这里：文档号必须是段内连续的小整数。Lucene 的 docID 是段内序号，不是你的业务主键，而且合并之后会重新编号。任何把 Lucene docID 当作稳定标识存到外部的做法都会在某次合并后炸掉。

打分：TF-IDF、BM25，以及它在流程里的位置#

匹配和排序是两件事。倒排表求交回答"哪些文档匹配"，打分回答"哪些排在前面"。Lucene 的执行流程是：迭代匹配的文档 → 逐个算分 → 丢进一个容量为 k 的最小堆 → 堆顶就是当前第 k 名。

打分公式的两代主角：

BM25 胜出的关键是词频饱和。在 TF-IDF 里，一篇文章重复"纠缠"一百次，得分就一路涨上去，垃圾内容很容易靠堆砌关键词冲榜；BM25 让第 1 次出现贡献很大、第 10 次贡献很小、第 100 次几乎不再增加——这更符合"出现过就说明相关，出现很多次并不说明相关一百倍"的经验事实。

有一个实现细节值得知道：BM25 需要文档长度做归一，而 Lucene 把每个字段的长度用一个字节有损编码后存进 norms（.nvd/.nvm）。这意味着长度归一天然是粗粒度的——长度 1000 和 1100 的文档在打分上可能完全一样。想省掉这一字节也可以（mapping 里 norms: false），代价是彻底失去长度归一。

真正把打分从"最后一步"变成"贯穿全程的剪枝依据"的，是 Block-Max WAND。原始 WAND 由 Broder 等人在 2003 年提出，Ding 与 Suel 在 2011 年扩展为按块记录最大得分的版本，Lucene 8.0（2019 年 3 月）把它实现进了默认的查询路径。思路是：在写倒排表时，为每一个 128 文档的块预先算好"该块内单词项能贡献的最高分"并存下来；查询时维护当前第 k 名的分数作为门槛，如果某几条倒排表在某个区间内的最大分之和还不到门槛，整段区间连解压都不必，直接跳过。Grand、Muir、Ferenczi 与 Lin 在 2020 年 ECIR 的论文里报告，在 Lucene 自己的基准套件上这带来了 3 到 7 倍的查询评估性能提升。

代价非常具体，而且每个 Elasticsearch 用户都撞到过：总命中数不再精确。既然整块被跳过，你就不知道里面有多少匹配。于是 ES 7.0 起 hits.total 变成一个对象，默认只精确统计到 10000，超过就报 "relation": "gte"；想要精确总数必须显式 track_total_hits: true，把这项优化关掉。分页深度受限（index.max_result_window 默认 10000）也是同一族约束的产物——top-k 堆的机制决定了取第 10000 到 10010 名必须先把前 10010 名都算出来。

段：不可变性买到的一切#

现在说 Lucene 最核心的结构决定。索引不是一个大文件，而是一组段（segment），每个段是一个完整的、独立的、写完之后永不修改的迷你索引。

一个段的典型文件构成：

_0.si                段元信息
_0.tim / _0.tip      词项字典 / 词项索引（FST）
_0.doc               文档号与词频（倒排表主体 + 跳表 + 块最大分）
_0.pos / _0.pay      词的位置 / 偏移与 payload（短语查询、高亮用）
_0.fdt / _0.fdx      stored fields（原文），默认 LZ4 压缩
_0.dvd / _0.dvm      doc values（列式，排序与聚合用）
_0.nvd / _0.nvm      norms（长度归一因子）
_0_1.liv             活跃文档位图 —— 唯一会变的东西
segments_5           提交点：这一次提交由哪些段构成
```

除了 .liv，所有文件写完即封存。这个约束换来了四件事，全都是搜索系统的命脉：

1. 读取彻底无锁。 一个 IndexReader 打开的是一组确定的段，写入者在旁边造新段，读者不需要任何同步原语，也永远不会看到半成品。这是搜索引擎能把读并发做到极致的根本原因。
2. 缓存永不失效。 段不会变，所以它的任何派生物——操作系统页缓存、过滤器缓存、块最大分——都不需要失效逻辑。缓存失效之所以是计算机科学两大难题之一，是因为数据会变；数据不变，难题就不存在。
3. 复制退化成拷文件。 Elasticsearch 把主分片同步给副本、做快照到对象存储，本质都是拷贝一批不可变文件加一份段清单。
4. 崩溃恢复简单。 提交是两阶段的：先把所有段文件写完并 fsync，再原子地写出新的 segments_N。崩溃发生在中途，重启后读到的仍是上一个完整的 segments_N，那些没被任何提交点引用的孤儿文件直接删掉。没有回滚逻辑，因为没有东西被改坏过。

代价只有一个，但它很贵：既然不能改，写入就只能不断产生新段；段越来越多，每次查询都要在每一个段上分别执行再归并结果，成本随段数线性上涨。于是必须有人来收拾——这就是合并。

合并：把不可变性的账单付掉#

合并（merge）把若干个小段读出来，重新写成一个大段，过程中顺手把标记删除的文档真正丢弃、把文档号重新连续编号。这是不可变设计的账单，而且是写放大形式的账单：同一篇文档在它的一生中可能被物理重写四五次，每次都要重新压缩倒排表、重建 FST。

Lucene 默认的 TieredMergePolicy 用几个参数决定何时动手：

三行数字解释了大量现场问题。为什么 _forcemerge?max_num_segments=1 是个陷阱：它会造出一个远超 5 GB 的巨段，而巨段超出了常规合并的尺寸上限，此后它里面积累的删除几乎永远不会被回收——Elastic 的文档因此明确建议只对不再写入的只读索引执行 forcemerge。为什么删掉 10% 的数据磁盘纹丝不动：10% 没到 33% 的阈值，合并策略认为不值得为此重写数据。为什么大批量删除之后磁盘反而先涨后跌：合并期间新旧两份数据同时存在，峰值需要额外的空间。

合并还会和查询抢 I/O 和 CPU。写入高峰期搜索延迟毛刺，十有八九是几个大合并同时在跑；合并线程数（index.merge.scheduler.max_thread_count）在机械盘上必须调小、在 SSD 上可以放开，就是因为合并是顺序读写密集型的。

近实时：那 1 秒钟到底在等什么#

新写入的文档先进 IndexWriter 的内存索引缓冲区，此时任何 reader 都看不见它。让它可见需要一次 refresh：把缓冲区里的内容组织成一个新段、写到文件系统里、然后打开一个新的 reader 把这个段纳入视野。

关键在于这一步不需要 fsync。新段只写到操作系统的文件系统缓存里就算数——对读取来说它已经是一个完整可查的段，对持久性来说它还悬在空中。这正是 Lucene 自 2.9 时代引入近实时读者以来的核心把戏：把"可见"和"持久"拆成两件独立的事。

那持久性由谁负责？Elasticsearch 的答案是事务日志（translog）：每个写请求在进入 Lucene 缓冲区的同时也追加到 translog，默认 index.translog.durability: request——每个请求都 fsync translog 之后才向客户端返回成功。段丢了不要紧，重放 translog 就能重建。

三个经常被混用的词，在这里必须分清：

这套机制的推论也很实用：批量导入时把 refresh_interval 设成 -1，能省下大量"生成小段、又立刻被合并掉"的无用功，导完再设回来；写完立刻要读的场景可以用 ?refresh=wait_for，它让请求等到下一次 refresh 而不是强制触发一次；Elasticsearch 还有个 index.search.idle.after（默认 30 秒）——超过这个时间没有搜索流量的分片会停止后台 refresh，直到下一次搜索到来。这解释了一个反复被当成 bug 的现象：闲置索引写入后立刻查不到，而第二次查询就查到了。

"更新一篇文档"实际发生的事#

把前面所有东西拼起来，这句话的真正含义是：

updateDocument(term, newDoc):
  1. 在包含旧文档的那个段的 .liv 位图里，把它那一位置 0
  2. 把 newDoc 完整写进内存缓冲区，等待下一次 refresh 变成新段
  3. 旧文档的所有词项、倒排表、原文，原封不动留在原段里
  4. 直到某次合并把那个段重写掉，它们才被真正丢弃
```

这四行是理解 Elasticsearch 运维现象的总钥匙：

Lucene 后来确实开了一个小口子：doc values 列可以原地更新（updateNumericDocValue 一类接口），因为列式结构改一个数值不牵动倒排表。Elasticsearch 用它实现了软删除等内部功能，但它对倒排字段无效——你没法用它改一个可搜索的文本字段。这个例外恰恰印证了规则：能原地改的，都是不参与倒排索引的部分。

这套设计在什么场景下失效#

只讲优点是不诚实的。倒排索引 + 不可变段这套组合有清晰的适用边界：

• 高频小更新：每秒更新同一批文档几千次的场景（在线计数、实时库存、会话状态），写放大会把系统吃穿。这类需求应该交给 Redis 或关系数据库，让 Lucene 只承担检索。
• 强一致的读己所写：refresh 窗口意味着写完立刻读不一定看得见。要么用 ?refresh=wait_for 付延迟，要么接受这个语义。
• 深分页：top-k 堆决定了第 N 页的成本与 N 成正比。翻很深的页应该改用 search_after 这类游标式接口。
• 精确总数与聚合：Block-Max WAND 用精确 hit count 换速度；聚合走的是 doc values 而非倒排索引，内存模型完全不同。
• 纯向量语义检索：Lucene 9.0（2021 年 12 月）引入了基于 HNSW 图的向量检索，它和倒排索引是并列的另一套结构，共享段与合并机制，但不共享倒排表那一整套压缩与剪枝逻辑。把语义检索理解成"倒排索引的升级版"是错的，它是搭在同一具骨架上的另一个器官。

Lucene 的全部智慧，其实浓缩在一个判断里：把可变性从数据结构里彻底赶出去，然后用一个后台进程定期偿还由此产生的债务。 这个判断让读取无锁、缓存永生、复制变成拷文件、崩溃恢复不需要回滚；它也让删除变成墓碑、更新变成重写、空间回收变成一件需要调参和排期的运维工作。你在 Elasticsearch 上遇到的绝大多数意外，都是这笔交易的另一面在向你出示账单。

跨域连接#

• 概率论：BM25 不是拍脑袋凑出来的经验公式，它出自 Robertson 与 Sparck Jones 的概率检索框架——检索被形式化为"给定查询，估计每篇文档相关的概率，并按该概率降序排列"，即概率排序原则（PRP）——在这个框架下，IDF 项其实是一个对数几率：一个词在整个语料里越罕见，"文档含此词"这一观测对"文档相关"的似然比贡献就越大，取对数之后正好变成可加的证据。词频饱和项则来自 2-Poisson 模型的近似：假设词在"相关文档"和"不相关文档"里服从不同强度的泊松过程，推导出的得分函数天然带有上界。理解这一点会改变你调参的方式——k₁ 和 b 不是任意旋钮，它们是模型在真实语料上被拟合出来的近似参数，脱离语料谈"最优 k₁"没有意义，而这也解释了为什么 BM25 在中文短文本上常常需要重新标定。
• Unicode 与数字书写：倒排索引里存的从来不是你写下的字符串，而是分析链输出的词项，而这条链的每一步都是 Unicode 层面的决策——大小写折叠要不要用 Unicode 的 case folding 而非简单的 toLowerCase（土耳其语的无点 i 会因此被错误合并）、要不要做 NFC/NFKC 规范化（同一个"fi"连字与"fi"两个字符在字节上完全不同，不规范化就永远搜不到彼此）、组合字符与预组合字符如何统一、全角半角要不要折叠。中文更极端：没有词边界，索引器必须在二元切分与词典分词之间做出选择，而这个选择决定了"京东方"会不会被切成"京东/东方"从而把一家面板厂商的文档匹配到电商查询上。这些决定在写入时就固化进了段里，事后无法回滚——索引与文字编码的耦合，比大多数人以为的紧密得多。
• 记忆系统：人的语义记忆提取与倒排索引查表在结构上惊人地相似——线索（cue）激活相关条目，而不是遍历全部经验——心理学称之为线索依赖提取，这正是"从词项出发反查文档"而非"逐篇扫描"的生物版本。更有意思的是遗忘：提取诱发遗忘（retrieval-induced forgetting）表明，被"忘掉"的记忆往往不是被抹除，而是被抑制、被更强的竞争者压住，条件合适时仍可能重新浮现——这与 Lucene 的墓碑式删除是同一个结构：内容还在，只是在检索路径上被屏蔽了。而睡眠期的记忆巩固，把零散的日间痕迹整理为结构化的长期表征，其角色几乎就是合并（merge）——都是在后台把碎片重写为紧凑形式，都需要占用系统资源，也都在被打断时留下代价。
• 印刷术：书末索引作为一种知识技术，是随着印刷术的普及才真正成立的——手抄本时代每一份抄本的页面切分都不同，"第 137 页"这个指针在别人的抄本上毫无意义，索引因此无法在副本之间流通；印刷带来的是同一版内所有印本页码完全一致，指针第一次有了跨副本的稳定所指，词条—页码这种倒排形态才成为可复制的公共基础设施。这与 Lucene 的段结构是同一种约束：指针要可用，被指向的东西就必须不可变。而印刷业的"再版"也精确对应了合并——改一处正文不能挖字，只能重排整页乃至整个印张，改动的最小单位是版而不是字，正如 Lucene 里改动的最小单位是文档而不是字段。
• 真理是什么：搜索引擎排在第一位的结果，从来不宣称自己是"真的"，它只宣称自己得分最高——BM25 计算的是词项分布上的统计契合度，一篇把关键词分布调得恰到好处的低质量文章，可以在纯词项模型下击败一篇权威但用词克制的论文。这是把"好"操作化为可计算指标时不可避免的滑移：指标一旦成为排序依据，就同时成为被优化的目标，SEO 产业的全部存在就建立在这条缝隙上。相关性是一个符合论意义上无法被检验的概念——没有哪个函数能验证文档与世界的对应关系，能验证的只有文档与查询在符号层面的吻合。承认这一点，才能理解为什么现代搜索必须在 BM25 之上再叠加链接分析、点击反馈、权威性信号乃至人工评审：不是因为 BM25 算错了，而是因为它回答的本来就是另一个问题。

参考文献#

• Doug Cutting, Jan Pedersen, "Optimizations for Dynamic Inverted Index Maintenance", SIGIR 1990。—— Lucene 作者本人在写出 Lucene 前九年发表的倒排索引增量维护研究，"缓冲加合并"这条思路的直接来源。
• Justin Zobel, Alistair Moffat, "Inverted Files for Text Search Engines", ACM Computing Surveys 38(2), 2006。—— 倒排文件的权威综述，差分编码、位打包、跳表与求交策略的系统性比较。
• Stephen Robertson, Hugo Zaragoza, "The Probabilistic Relevance Framework: BM25 and Beyond", Foundations and Trends in Information Retrieval 3(4), 2009。—— BM25 的完整推导与参数意义，由公式作者亲自撰写。
• Andrei Broder, David Carmel, Michael Herscovici, Aya Soffer, Jason Zien, "Efficient Query Evaluation using a Two-Level Retrieval Process", CIKM 2003。—— WAND 算法原始论文，动态剪枝的起点。
• Shuai Ding, Torsten Suel, "Faster Top-k Document Retrieval Using Block-Max Indexes", SIGIR 2011。—— 把最大得分下沉到块级别的 Block-Max WAND 原始论文。
• Adrien Grand, Robert Muir, Jim Ferenczi, Jimmy Lin, "From MAXSCORE to Block-Max Wand: The Story of How Lucene Significantly Improved Query Evaluation Performance", ECIR 2020。—— Lucene 8.0 落地这项优化的第一手记述与基准数据。

延伸阅读#

• Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze, Introduction to Information Retrieval, Cambridge University Press, 2008。—— 信息检索的标准教材，前六章几乎就是本文所有机制的形式化版本，可全文免费阅读。
• Michael McCandless, Erik Hatcher, Otis Gospodnetić, Lucene in Action, 2nd Edition, Manning, 2010。—— 版本虽老，但对分析链、段生命周期与 IndexWriter 语义的讲解至今没有更好的替代品；作者 McCandless 的博客 Changing Bits 上还有段合并过程的动态可视化。
• Apache Lucene 官方 API 文档中 ...PostingsFormat 类的"文件格式"章节（如 Lucene84PostingsFormat）。—— 字段级的权威定义：.tim/.tip/.doc/.pos 的字节布局、128 元素块的打包规则、跳表结构，都在这里逐项写明。