fsearch 真有那么快？先把它的本事和短板说清楚
号称在 800 万文件里 1 毫秒命中，fsearch 凭什么这么快，又有哪些场景它接不住？
适合：macOS 上需要快速模糊搜文件名并兼顾正文检索的重度文件管理用户。
先说结论
fsearch 不是一个新概念，它做的就是 macOS 上 Spotlight 没做好的那一块：全盘文件名搜索加模糊匹配，再叠一层已经建好索引的正文 grep。一周内拿到 1156 颗星，说明很多人等的就是这个组合。Rust 写的，所以吃内存少、响应快是天然的。它适合文件多、目录深、经常按名字或片段翻旧项目的人；不适合只想搜系统设置、看图找图、或者数据量本就不大的轻度用户。
真正的问题
原生 Spotlight 慢，不只是慢在“搜得久”，更让人烦的是结果飘忽：明明文件就在那儿，关键词也对，Spotlight 就是不返回。这背后是索引范围、更新策略和权限边界那一摊事。日常被卡住，主要是这几类场景。
- 名字记不全：只记得
report_final_v2里的final，或者大小写拼错一位，Spotlight 要靠精确子串才肯命中。 - 后缀混乱：日志、备份、临时文件一大堆，扩展名随机，
grep命令行能搞定但要写表达式。 - 正文藏线索：合同号、报错堆栈、配置项埋在文本里，没索引就只能靠
mdfind碰运气，或者干脆grep -r。 - 库太大：开发机、素材盘、镜像仓库挂上来，几百万文件一过，普通工具直接卡到转圈。
怎么做更省力
fsearch 的核心做法是把 Spotlight 那套“全系统通吃”换成“自己说了算”：你指哪块盘就索引哪块盘，名字走 trigram 模糊匹配，文本走预先建好的倒排索引。所以上手步骤很朴素。
1。 装好后先别急，把常用盘（工作目录、素材库、代码仓）手动加进索引清单。 2。 模糊搜索直接用，比如输入 rprt_fnal，也能命中 report_final。 3。 想搜正文就切到“内容”模式，第一次会比纯名字慢，因为它要扫索引，但建好之后就是亚秒级。 4。 配合快捷键全局唤起，相当于给 Finder 加了一根“快进”的进度条。
如果你的工作流经常要把模糊名字和正文片段混着查，fsearch 能省下不少切窗口的时间。如果只是想给项目里的几百个文件做归档整理，顺手用长文配图专家拆场景更划算，跟搜索是两码事。
| 维度 | fsearch | macOS Spotlight | 命令行组合（find + grep） |
|---|---|---|---|
| 模糊匹配文件名 | 强，原生支持 | 弱，需精确子串 | 需正则或通配 |
| 正文检索速度 | 快，建索引后毫秒级 | 不稳定，看心情 | 实时扫，慢在大目录 |
| 资源占用 | 低，常驻后台轻 | 中，会和系统抢资源 | 几乎为零 |
| 上手成本 | 中，要手动指定路径 | 低，开箱即用 | 高，要会表达式 |
哪些坑要避开
工具不坑，坑在用法。
- 别把整块机械硬盘也丢进去索引，速度上不去，索引体积还膨胀。
- 外接盘、网盘、加密宗卷要先挂稳再索引，否则索引里会有“鬼文件”。
- 系统目录、Time Machine 备份这类别动，权限和体量都容易出事。
- 正文搜索默认对二进制文件也建索引，关掉能省一大块空间，除非你确实要在
.pdf、.log里翻东西。 - 模糊匹配适合名字，对路径层级不要依赖太重，目录结构一变，结果就漂。
现在就能动手
按这个顺序做，十分钟内就能判断它适不适合你。
1。 下载安装，授予“完整磁盘访问”和“辅助功能”权限，这是被卡住最多的一步。 2。 先把一个项目目录加进索引，等它跑完一轮，立刻用模糊词试一次。 3。 切到“内容”模式，挑一个常用关键词，比如你公司的客户代号，再搜一次，感受下命中延迟。 4。 如果连续两天都觉得顺手，再把素材盘、文档盘陆续纳入；如果用不到，就别硬塞。 5。 别忘了定期清理索引目录，删除已经下架的项目，工具会越用越快。