Cardinal: 最快最准的 macOS 文件搜索工具（开源）

[ldm0]

怎么又来了

上次发布收到了很多建议和反馈，有很多启发。4 个月的迭代之后，如今的 0.1.23 版我用的很满意，因此再次向大家推荐 Cardinal 。

亮点

Cardinal 可以做到：

1. 毫秒级的文件搜索，结果比 Spotlight 更精准
2. 千万文件单列表渲染
3. 丰富的搜索语法支持（搜索语法是 Everything 的超集)

注：这个图是在低配 MacBook Neo 上录的

适用人群

如果你觉得翻找文件困难，并且发现 Spotlight 结果不全有遗漏；

如果你怀念 Windows 上的 Everything ；

如果你是 FAF(Find Any File)、Houdahspot 、EasyFind 、Cling 的用户；

强烈推荐你们试用一次 Cardinal 。一方面免费软件试试没什么成本；一方面就我个人体验而言，Cardinal 比其它软件更快更准

代码和下载

代码是开源的： https://github.com/cardisoft/cardinal

你可以在这里下载 Cardinal，也可以直接:

brew install --cask cardinal-search

《搜索语法大全》

闲聊

Spotlight 真的不准，而 macOS 的文件搜索软件无论收不收费也都没有办法做到实时的精准的搜索，因此做了这么个小工具。有很多人给好评和意见，很感恩。

几个我常用的搜索命令:

# 大于 100m 的压缩包
*.zip size:>100m

# 找电脑上不知道装在哪的 clang
/clang/

# 所有飞书表情包 😅
LarkShell/**/stickers/**

[YmPillar]

感谢分享, macos 里一直需要一个 everything, 赞

[hackpro]

感谢

看了下路径检索主要是针对文件名
支持文件内容检索吗

[hackpro]

另外反馈下可否针对某个文件夹或者外置硬盘单独进行检索
以及文件/文件夹📁去重支持？

[ldm0]

@hackpro 这个主要对标 Everything ，没有文件内容的索引。但是支持按文件内容过滤，示例："*.txt content:xxx"

https://github.com/cardisoft/cardinal/issues/96

[ldm0]

@hackpro 支持单独检索，可以打开设置调整一下根目录；没有去重的功能。

[hackpro]

@ldm0 感谢回复
所以这个主要是路径/文件名搜索（类似于 fd ）对吧

[ldm0]

@hackpro 对的

[Ccf]

跟 raycast 的搜索比呢？

[inostarling]

很好用，感谢！

[ldm0]

@Ccf 当然是更准啦，raycast 的搜索本质就是 Spotlight

[xing7673]

搜索文件的时候真怀念 windows 的 nfts 系统

[ldm0]

@xing7673 NTFS 有 USN Journal + MFT ，APFS 没没有等价物，只有一个系统级的 FSEvents ，这也是 Cardinal 实现的最难的点之一。

不过这些问题都尽力调和了，你应该可以在 Cardinal 里面找到 Everything 的感觉。

[chachi]

能兼容 everything 的 etp 协议就好了。
可以外挂 winserver 上的 everything ，并且映射转换到 smb 路径。
这样就比较完美了。

[ldm0]

@chachi 整！

[elviscai]

打开设置里的「显示托盘图标」后会隐藏 dock 图标（？

[ldm0]

@elviscai 对呀，要么在 Dock 里面，要么在托盘上，没有两边都在的需求吧(？

[xiaoke]

这个可以有😁

[duhbbx1119]

@hackpro 文件内容的感觉想想都不好做，还得建索引 :)

[hackpro]

@duhbbx1119 我现在路径检索用 fd 内容检索用 ag

[imaxwell]

感谢大佬，后续整个 mcp 对接 ai 支持语音发起检索就更爽了

[maladaxia]

很棒, 可以集成到 raycast 吗

[ldm0]

@maladaxia 在计划中了。raycast 集成有好多人在说，那么好用么（

[longmeidao]

我记得 Houdahspot 是可以搜索文件内容的，可能没法完全对标？😂

[ldm0]

@longmeidao Houdahspot 的文件内容索引完全使用 Spotlight 的，什么情况下会用 Houdahspot 而不是 Spotlight 来搜索文件内容呢。

如果是强需求，我可以弄下在没有其它 query 的情况下的 Spotlight fallback

[yohance]

违法广告法了兄 der ～

[ldm0]

@yohance 小众软件推广不易，理解一下（

但是效果确实值得试试的

[explorerproxy]

不支持快捷键快速打开搜索窗口么

[ldm0]

@explorerproxy 支持的 cmd + shift + space
可以看看 readme

[explorerproxy]

@ldm0 #28 看到了，习惯性打开设置界面没找到设置的地方，后续如果能自定义就好了

[ldm0]

@explorerproxy 在做了: https://github.com/cardisoft/cardinal/pull/166
不过最近打工有点忙，过两天更新一下（

[94nb]

从 10 点折腾这个软件到现在，大概记住了常用的过滤条件写法，不过有些组合搜索条件还是拼不对，啥时候能加入手动选筛选条件呀，这样在记不住那么多条件的时候也能通过手选组合条件

[ldm0]

@94nb 辛苦了（，自动补全或者图形化的点选会有帮助么。

[94nb]

@ldm0 自动补全意义不大，不是记不住过滤的参数，是在使用过程中有些条件不知道怎么组合。我自己组合了半天，又把 github 上的 md 扔给 gemini 让他帮我，都没搞定,直到现在我也没搞定。。。

我的工作多数是写文档，在有新的文档要写时，很多时候我只记得我前段时间写过这方面的内容，现在只记得个大概，所以经常要用搜索功能（如果有内容搜索就更依赖了，现在的 content 搜起来太慢了，遥遥无期，基本算是不可用吧，如果这个也能搞定，那我很愿意付费）。我不懂研发，这个软件我觉得对我是有帮助的，这些过滤参数的用法我也愿意学，但对于想拿起来就用的用户群体来说，还是有一定的学习成本，如果加入图形化的点选，对同样像我这样不懂研发的人会有极大的帮助。

我目前遇到的问题在下面描述了一下，我觉得更多是我还不会用，并不是目前的软件不能实现，我怕我描述的不清楚，让 gemini 帮我润色了一下：

问题背景：
在日常使用中，我经常遇到需要“跨层级”搜索特定文件的情况。例如：
路径模糊：我记得文件夹名包含 aAa ，但不记得它的绝对路径或层级。
文件特征：文件名包含 bbb 。
格式限制：后缀名为 .doc 或 .docx 。

尝试与痛点：
虽然查阅了文档并咨询了 AI ，但以下几个逻辑问题依然困惑：

问题 1：目录过滤条件的混淆
文档中提供了 folder:、parent:、in:、nosubfolders 以及路径分隔符 / 等多种组合方式。作为非开发人员，很难理解这些条件的底层差异，尤其在面对“只记得部分目录名且不知深度”的情况下，不知道该如何组合这些参数。

问题 2：大小写敏感性的不一致
在某些目录过滤条件下，必须与实际名称大小写完全一致才能匹配；而另一些条件却不需要。这与界面上的“大小写匹配”开关逻辑似乎是冲突的，导致在不确定目标文件夹准确拼写时，搜索效率极低。

问题 3：双引号精确匹配的预期落空
按理解，双引号内应为“完全匹配”（如搜索 "1 到 10.png" 应仅返回该文件）。但实际操作中发现，搜索 "aaa" 的结果往往等同于模糊匹配 *aaa*，包含了大量无关项，无法达到“我写什么就只出什么”的效果。

[94nb]

@94nb #33 忘记说了一点，能不能右键加入删除呀，搜出来的内容想批量删掉。

[ldm0]

@94nb 感谢这么详细的使用和建议，辛苦了🙏，对俺很有帮助～

> 现在的 content 搜起来太慢了，遥遥无期

由于之前有准确性的执念没有复用 Spotlight 索引，content 这块是直接全文搜索，所以确实慢。这块我最近放下执念了（实用为主），可以复用 Spotlight 索引再配合我们的搜索规则一起工作。

> 路径模糊：我记得文件夹名包含 aAa ，但不记得它的绝对路径或层级。
> 文件特征：文件名包含 bbb 。
> 格式限制：后缀名为 .doc 或 .docx

*aAa*/**/*.doc* 这样 glob 匹配可以，但是这个确实有点绕，先凑合用。

> 文档中提供了 folder:、parent:、in:、nosubfolders 以及路径分隔符 / 等多种组合方式。作为非开发人员，很难理解这些条件的底层差异，尤其在面对“只记得部分目录名且不知深度”的情况下，不知道该如何组合这些参数。

这个是从 Everything 继承过来的语法，但是都不适用于部分目录名。这个和上面是一个需求，这块接下来不会通过新语法来提供，将会有一个单独的左侧可折叠的输入框来专门 scope 文件夹。

> 在某些目录过滤条件下，必须与实际名称大小写完全一致才能匹配；而另一些条件却不需要。这与界面上的“大小写匹配”开关逻辑似乎是冲突的，导致在不确定目标文件夹准确拼写时，搜索效率极低。

这个可以具体说下么，感觉是 bug

> 按理解，双引号内应为“完全匹配”（如搜索 "1 到 10.png" 应仅返回该文件）。但实际操作中发现，搜索 "aaa" 的结果往往等同于模糊匹配 *aaa*，包含了大量无关项，无法达到“我写什么就只出什么”的效果。

双引号其实是防转义，比如空格其实是 AND 的语义，分号是 OR 的语义，双引号标起来的东西是防止语义替换，比如 "1 到 10.png" 这里真的会匹配空格。你的需求其实在这里可以通过： /"1 到 10.png"/ 全匹配； /"1 到" 前缀匹配；"到 10.png"/ 后缀匹配。

> @94nb #33 忘记说了一点，能不能右键加入删除呀，搜出来的内容想批量删掉。

因为搜索列表很大，多选删除有风险，所以一开始没做。后面考虑做一下，需要加弹窗确认。



总的来说学到很多，有些问题之前也意识到但是觉得没那么高优。这几个东西我会推进做一下，应该很快会有新版本，到时候 ping 你试试，看看够不够用 :-)

[94nb]

@ldm0 #35

> *aAa*/**/*.doc* 这样 glob 匹配可以，但是这个确实有点绕，先凑合用。

结合着你这个示例，我看明白该怎么写了，之前我一直执着于用那些参数，尝试着 folder:aAa ext:doc|docx bbb 这样 ，现在尝试用*以及不去故意写那些参数，现在大多数都能搜到了

> 在某些目录过滤条件下，必须与实际名称大小写完全一致才能匹配；而另一些条件却不需要。这与界面上的“大小写匹配”开关逻辑似乎是冲突的，导致在不确定目标文件夹准确拼写时，搜索效率极低。

我刚具体尝试了一下几个目录的参数：
folder 会根据按钮设定大小写
in 没有按照按钮设定大小写
parent 没有按照按钮设定大小写
nosubfolders 没有按照按钮设定大小写

不过这已经不重要了，我已经学会不依赖这些参数，而用*来搜索了

精确匹配也学会了

删除这个弹窗我觉得没问题，重要操作应该有弹窗确认

其实还有一个我觉得很不方便的点，但会用了上面那些搜索后这个也不是很重要了，不过还是说一下：
在过滤框里，我输入/Users/，现在显示出来的就是精确匹配的 users 的文件和文件名。其实这时候我觉得应该是列出/Users/**/*的内容。我刚特意找了个 windows 装了 Everything 最新版测试了一下，他显示的就是/Users/**/*的内容，而且更棒的一点是它把文件夹放在了最上边，这样方便我再精确的往下级目录写。我想了一下 Everything 的实现方式，它好像是在输入/Users/的时候，显示的是/Users/**/*，然后输入/Users/aa 的时候，显示的是/Users/*aa*这样，我觉得这样很方便😂

做产品肯定有个优先级嘛，先满足大部分使用人群以及常用功能，小的地方就慢慢打磨了，不过功能越多，软件就会越重，问题就会越多，我发现的这些也许都不是啥重要功能，还是得针对性的取舍。😂😂😂

[ldm0]

> 在过滤框里，我输入/Users/，现在显示出来的就是精确匹配的 users 的文件和文件名。其实这时候我觉得应该是列出/Users/**/*的内容。我刚特意找了个 windows 装了 Everything 最新版测试了一下，他显示的就是/Users/**/*的内容，而且更棒的一点是它把文件夹放在了最上边，这样方便我再精确的往下级目录写。我想了一下 Everything 的实现方式，它好像是在输入/Users/的时候，显示的是/Users/**/*，然后输入/Users/aa 的时候，显示的是/Users/*aa*这样，我觉得这样很方便😂

好的，这个我之前还真没留意到，我晚上找个 windows 试试看