1. 为什么文件名搜索已经不够用了用了这么多年 Everything我猜你跟我一样早就把它当成 Windows 上开机必启的常驻工具了。敲几个字母目标文件瞬间出现在列表里那种秒出结果的爽感是 Windows 自带搜索永远给不了的。但用久了你会发现一个越来越明显的短板它只能搜文件名和路径搜不了文件里面的内容。这个限制在早期其实不算什么大问题。那时候大家的硬盘里无非是些文档、图片、压缩包靠文件名基本能定位。可现在情况完全变了。我自己的资料盘里躺着几千个 Markdown 笔记、上百份 PDF 报告、一堆代码文件和各种配置文件很多文件的命名是2024-03-15-会议记录.md或者config-backup.json这种光看名字根本不知道里面写了什么。想找上个月讨论过缓存穿透的那份笔记靠文件名搜索等于大海捞针。这就是 Everything 1.5 要解决的核心问题。它在原有的 NTFS 索引引擎之上加了一层**内容索引Content Indexing**能力让你可以像搜文件名一样去搜文件正文。注意这不是简单地在搜索时临时去读每个文件而是建立了一套独立的、可配置的内容索引体系。理解这一点非常关键因为它直接决定了搜索速度、资源占用和使用体验。我先把结论摆在这里Everything 1.5 的全文搜索不是开箱即用的功能它需要你主动配置索引范围、选择索引哪些类型的文件、决定用哪种索引方式。配置得好它是神器配置得随意它可能吃掉你几十 GB 的磁盘空间还拖慢系统。所以这篇文章的重点不是怎么打开这个功能而是怎么把它调教成真正好用的样子。适合读这篇的人有三类一是已经装了 Everything 1.5 但还没搞明白内容索引怎么配的老用户二是被 Windows 自带搜索折磨够了、想找个靠谱替代方案的人三是手里有大量文本类资料、需要频繁做全文检索的知识工作者和开发者。如果你属于这三类中的任何一类接下来的内容应该能帮你少走不少弯路。2. Everything 1.5 内容索引的底层逻辑2.1 文件名索引和内容索引是两套独立系统很多人第一次用 Everything 1.5 的全文搜索时会困惑为什么我明明开了内容索引搜某些词还是搜不到答案在于Everything 的文件名索引和内容索引走的是完全不同的两条路。文件名索引依赖的是 NTFS 文件系统本身的USN Journal更新序列号日志。这个日志记录了磁盘上所有文件的增删改操作Everything 直接读取它所以能在几秒内建好整个盘的索引而且几乎不占额外空间。这也是为什么 Everything 第一次启动就能瞬间列出你所有文件——它根本没去遍历文件只是读了日志。内容索引就没这么幸运了。文件内容不在 USN Journal 里Everything 必须真的去打开文件、读取内容、分词、建立倒排索引。这个过程慢得多而且索引数据要单独存盘。所以 Everything 1.5 把内容索引设计成一个可选的、按需配置的子系统你可以精确控制索引哪些文件夹、哪些扩展名、用多大的内存和磁盘。提示内容索引和文件名索引是叠加关系不是替代关系。开了内容索引之后搜索时 Everything 会同时查两套索引文件名命中的和内容命中的结果会一起返回。2.2 两种索引模式快速索引与完整索引Everything 1.5 在内容索引上提供了两种模式这个区分非常重要选错了会直接影响你的使用体验。快速索引Fast Indexing只索引文件开头的一小段内容默认大概是前几 KB。它的逻辑是大多数文本文件的核心信息都在开头比如文档标题、代码的 import 段、配置文件的头部。这种方式索引速度快、占用空间小但缺点是如果关键词出现在文件靠后的位置就搜不到。完整索引Full Indexing会把整个文件从头到尾读一遍并全部建索引。搜索准确率最高但代价是索引时间长、磁盘占用大。一个几十 MB 的日志文件如果做完整索引可能产生好几 MB 的索引数据。我的建议是分场景选择日常笔记、代码、配置文件这类文件普遍不大用完整索引完全没问题但如果你要索引大量日志文件或者超大的文本数据快速索引更划算。Everything 允许你针对不同的文件夹和扩展名分别设置这个灵活性要用起来。2.3 索引数据的存储位置与空间预估内容索引的数据默认存在 Everything 的配置目录里通常在%APPDATA%\Everything下面。这个目录会随着索引内容增长而膨胀需要提前有个心理预期。根据我的实测纯文本类文件txt、md、代码的索引体积大约是原文件的 30% 到 50%PDF 因为要先抽取文本再索引比例会低一些但抽取过程更耗 CPUOffice 文档docx、xlsx需要调用相应的解析逻辑索引体积和原文件大小关系不大主要看文本量。举个具体的例子我索引了一个约 2 GB 的笔记和文档文件夹最终索引数据占了大概 700 MB。这个比例供你参考。如果你的资料盘有几百 GB 的文本内容最好把索引目录放到空间充裕的盘上别让它把系统盘撑爆。3. 从零配置一套可用的内容索引3.1 确认版本与基础环境第一步永远是确认你装的确实是 1.5 版本。Everything 1.4 及更早版本没有内容索引功能界面里也找不到相关选项。打开 Everything看标题栏或者帮助 - 关于版本号必须是 1.5 开头。另外要确认你的文件系统。内容索引对 NTFS 支持最好因为可以复用文件名索引的基础设施。如果你的资料放在 exFAT 或者网络驱动器上内容索引虽然也能用但效率和稳定性会打折扣。我个人的做法是只对本地 NTFS 盘上的核心资料目录开内容索引移动硬盘和网络盘保持文件名索引就够了。3.2 在选项里找到内容索引入口打开 Everything进入工具 - 选项在左侧列表里找到内容索引Content Indexing这一项。如果你没看到这个选项八成是版本不对回去检查版本号。进去之后你会看到几个关键配置区索引的文件夹列表、文件类型过滤、索引模式选择、以及资源限制。这几个区域要配合着设置不能只看一个。3.3 精确圈定要索引的文件夹这是整个配置里最重要的一步也是最容易出错的地方。千万不要一上来就把整个 C 盘或者整个资料盘加进去。内容索引不是文件名索引它要真读文件范围越大初次建索引的时间越长后续维护成本越高。我的做法是分层添加第一层核心笔记目录比如D:\Notes这里面全是 Markdown 和 txt索引起来快价值高。第二层文档目录比如D:\Documents包含 PDF、docx 等按需索引。第三层代码仓库目录比如D:\Code只索引源码文件排除node_modules、.git、build这些目录。在添加文件夹时Everything 允许你设置排除规则。排除规则用分号分隔支持通配符。比如排除依赖目录可以写node_modules;.git;dist;build。这一步做得好能省下大量无谓的索引工作。注意排除规则是大小写不敏感的但路径分隔符要用反斜杠。如果你从别处复制路径过来带了正斜杠记得改过来否则规则可能不生效。3.4 用扩展名白名单控制索引范围Everything 默认会尝试索引它认识的所有文本类文件但它认识的未必是你想要的。更稳妥的方式是显式指定扩展名白名单。在内容索引设置里找到文件类型相关的选项把你要索引的扩展名列进去。我常用的白名单是这样的txt;md;markdown;log;ini;conf;cfg;json;yaml;yml;xml;csv;html;css;js;ts;py;java;go;rs;c;cpp;h;sh;bat;ps1;sql这个列表覆盖了绝大多数纯文本场景。如果你还要索引 PDF 和 Office 文档需要额外确认 Everything 是否启用了对应的解析支持这部分通常依赖系统里安装的相应组件。把白名单设好之后那些二进制文件、图片、视频就不会被误索引既省时间又省空间。3.5 选择索引模式并设置资源上限回到索引模式的选择。对于上面白名单里的纯文本文件我建议用完整索引因为它们体积小、文本密度高完整索引的收益远大于成本。对于 PDF 和 Office 文档如果数量不多也可以完整索引如果量大考虑先用快速索引试试效果。资源上限这块Everything 允许你限制索引占用的内存和 CPU。默认值对大多数机器够用但如果你在配置较低的机器上跑或者索引范围特别大建议把 CPU 占用限制调低一些避免建索引时系统卡顿。内存方面索引过程本身比较吃内存给足一点会更顺畅。配置完成后点确定Everything 会开始建立内容索引。这个过程可能要几分钟到几十分钟不等取决于你的数据量。建索引期间可以正常用文件名搜索不影响。4. 搜索语法把内容索引真正用起来4.1 区分文件名搜索和内容搜索配好索引只是第一步会用搜索语法才是关键。Everything 1.5 里默认的搜索是同时查文件名和内容的但你可以用前缀来精确控制搜哪里。file:前缀表示只搜文件名。content:前缀表示只搜文件内容。不加前缀则两者都搜。举个例子content:缓存穿透会返回所有正文里包含缓存穿透的文件而不管文件名是什么。file:report则只按文件名匹配。这个区分在结果很多的时候特别有用能帮你快速缩小范围。4.2 组合条件与布尔逻辑Everything 的搜索语法支持空格分隔的多关键词默认是 AND 关系也支持|表示 OR。配合内容搜索可以玩出很多花样。比如我想找正文里同时提到缓存和穿透的 Markdown 文件可以这样写content:缓存 content:穿透 ext:mdext:md限定只搜 Markdown 文件。再比如找正文里有TODO或者FIXME的代码文件content:TODO|FIXME ext:js;ts;py这种组合能力是 Everything 全文搜索真正强大的地方。你可以把文件类型、内容关键词、路径条件任意组合精确命中你要的东西。4.3 正则与高级匹配如果你需要更复杂的匹配Everything 支持正则表达式。开启正则模式后在搜索框右侧的菜单里切换可以用完整的正则语法来搜内容。比如找所有包含邮箱地址的文件content:regex:[\w.-][\w-]\.[\w.]正则搜索对内容索引的压力比较大因为它没法完全靠倒排索引加速可能需要回表扫描。所以除非必要日常还是用普通关键词搜索更高效。4.4 搜索结果里的内容预览Everything 1.5 在搜索结果里可以直接预览命中内容。选中一个结果下方或者侧边会显示文件内容片段命中的关键词会高亮。这个功能在确认是不是我要找的那份时特别省事不用一个个打开文件。如果预览没显示检查一下是不是在视图菜单里把预览面板关掉了。另外预览大文件时可能会有短暂延迟这是正常的因为要临时读取文件内容。5. 性能调优与常见坑5.1 索引建好之后磁盘占用暴涨怎么办这是最常见的抱怨。内容索引确实占空间但如果你发现占用远超预期通常是这几个原因一是索引范围圈得太大把一堆不需要全文搜索的文件也纳入了。解决办法是回到内容索引设置收紧文件夹范围和扩展名白名单。二是用了完整索引去处理大量大文件。日志文件、数据导出文件这类改用快速索引能省很多空间。三是索引数据没做清理。Everything 在文件删除后不会立即回收索引空间需要定期让它重建或者做压缩。在选项里通常有重建索引的入口定期跑一次能回收不少空间。5.2 搜索变慢或者结果不全如果你发现内容搜索明显变慢先看是不是用了正则或者模糊匹配。这两类查询没法完全走索引性能天然差。结果不全的情况八成是索引没覆盖到。检查你要搜的文件是不是在索引范围内、扩展名是不是在白名单里、索引模式是不是漏掉了文件后半部分的内容。我踩过一次坑用快速索引去搜一个长文档中间的关键词怎么都搜不到后来改成完整索引才解决。5.3 和 NTFS 8.3 短文件名的关系网上有个热词提到关闭 NTFS 8.3 文件格式的支持。这个设置和 Everything 的关系值得说清楚。NTFS 默认会为每个文件生成一个 8.3 格式的短文件名就是那种PROGRA~1的样子这是为了兼容很老的软件。这个功能对 Everything 的文件名索引没有直接影响因为 Everything 读的是 USN Journal不是靠短文件名。但如果你关闭了 8.3 支持某些老程序的兼容性可能受影响这跟 Everything 本身无关。我的建议是除非你有明确的兼容性需求否则不用特意去动这个设置。它和 Everything 的全文搜索性能没有直接关系别被一些似是而非的说法带偏了。5.4 索引目录放在哪块盘上索引数据默认在系统盘的%APPDATA%下。如果你的系统盘是 SSD 但空间紧张而资料盘是大容量机械盘可以考虑把索引目录迁到资料盘。Everything 的设置里通常可以改索引存储路径。不过要注意索引数据放在机械盘上搜索时的读取速度会慢一些。SSD 上搜索响应更快。这是个空间和速度的权衡看你更在意哪个。6. 几个真实使用场景的配置思路6.1 知识工作者的笔记全文检索如果你像我一样有大量 Markdown 笔记配置可以很简单把笔记根目录加进索引扩展名白名单只留md;txt用完整索引。这样搜某个概念在哪篇笔记里提过就是秒出结果。我还会给笔记目录单独设一个搜索书签一键切换到只搜笔记内容的模式避免被其他文件干扰。6.2 开发者的代码库检索代码检索的需求和笔记不同重点是排除依赖和构建产物。我的配置是索引代码根目录扩展名限定为源码类型排除规则里加上node_modules;.git;vendor;dist;build;target。这样索引的是真正你自己写的代码搜索哪个文件里用了这个函数非常高效。6.3 文档管理者的 PDF 检索PDF 检索的前提是 Everything 能抽取 PDF 文本。这通常依赖系统组件配置对了之后PDF 正文就能被搜到。我的经验是 PDF 用快速索引先跑一遍如果发现关键信息经常在文档后半部分搜不到再对重点 PDF 目录改用完整索引。7. 我踩过的几个坑和对应解法第一个坑是索引范围失控。我一开始图省事直接把整个 D 盘加进内容索引结果建索引跑了快一个小时索引数据占了十几个 GB而且里面大部分是我不需要全文搜索的媒体文件。后来老老实实按目录分层配置问题就解决了。第二个坑是扩展名白名单没设。默认配置下 Everything 会尝试索引它认为的文本文件结果一些我根本不想要的日志和缓存文件也被索引了。显式设白名单之后索引干净了很多。第三个坑是误以为开了内容索引就能搜所有格式。实际上 PDF、Office 文档需要额外的解析支持纯文本才是开箱即用的。搞清楚这一点之后我对不同格式的预期就合理了。第四个坑是索引数据没定期维护。用久了索引会碎片化搜索偶尔变慢。定期重建一次索引能恢复到最佳状态。我现在大概每个月重建一次成本不高体验提升明显。8. 关于 Everything 1.5 全文搜索的一点个人体会Everything 1.5 的内容索引不是那种打开开关就完事的功能它更像是一个需要你花点心思调教的工具。配置得当它能让你在几秒钟内找到任何一份文档里的任何一句话这种能力在信息量大的工作场景里价值极高。配置不当它就是个吃磁盘、拖速度的负担。我的核心建议就三条范围要精不要广白名单要显式不要默认索引模式要按文件类型区分对待。把这三条做到位剩下的就是享受秒级全文检索的爽感了。另外提一句内容索引和文件名索引的配合使用才是完全体。日常找文件用文件名搜索找内容用内容搜索两者切换自如这才是 Everything 1.5 相比旧版本最大的进步。用熟之后你会发现自己对文件放在哪这件事的焦虑感明显降低了——反正搜得到放哪都行。