先弄清默认行为，后面的判断才有依据
程序启动时读取每个本地卷的文件表，把文件名、所在路径、大小和修改时间这类元数据装进内存数据库。它读的是目录项，不打开文件本体，所以条目再多也能很快建好索引，之后输入关键词几乎即时出结果。
代价是正文不在里面。文档写了什么、表格填了什么，索引一概不知道。在搜索框里敲一句正文里的话，除非和某个文件名重合，否则不会有结果，看起来就像程序坏了。
要检索正文有两条路：一条是临时用 content: 前缀让这一次搜索去读文件，另一条是在选项里为指定扩展名建立内容索引。前者不改任何设置、随用随开；后者配置一次换长期便利，代价是索引体积和建立时间都会增加。
不动任何设置，先试这一条
写成 content: 再加上要查的句子，它告诉程序这次不只比对名字，还要打开文件读正文，多个词之间继续用空格分隔就行。
例如查报价单时限定 txt,docx,xlsx 三类。格式列得越窄，需要打开的文件越少，等待时间越短。
正文检索靠逐个读盘，第一次要等几秒到几十秒。中途重复敲只会让队列更长。
命中的条目同样显示路径与修改时间，先扫路径列确认是哪一份。
对照之后再决定这次用哪种写法
| 写法 | 限定的是什么 | 要付的代价 |
|---|---|---|
| content: 加关键词 | 让本次搜索去读文件正文 | 逐个打开文件，最慢的一档 |
| path: 目录名 | 把候选限制在某段路径下 | 不减慢单次读取，只缩小范围 |
| ext: docx | 只保留指定扩展名的文件 | 配合 content: 能省下不少时间 |
| 星号通配符 | 替代记不全的那几个字 | 写在越靠前的位置，候选越多 |
| 正则表达式开关 | 把输入当正则解析 | 写错就没有结果 |
这几项定错了，后面要么慢要么空
从最可能的那条原因开始
集中在开关位置与等待时间
名字在索引里，比对的是内存中的字符串；正文不在，只能临时打开文件读一遍。等多久取决于盘速和候选数量。
搜索期间磁盘占用会明显上升，搜完就回落。如果同时在跑别的重活，等人空下来再搜更稳。
不冲突。建好内容索引之后普通关键词也有机会命中正文，content: 仍可用于临时强制读取未建索引的格式。
先确认该扩展名已加进内容索引列表，再看文件编码是否可读。两条都排掉再考虑重建索引。
可以。在搜索框里叠加 path: 限定目录，或者把范围切到指定卷，候选文件少了，等待也短。