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

很棒, 可以集成到 raycast 吗

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

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

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

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

违法广告法了兄 der ～

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

但是效果确实值得试试的

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

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

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

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

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

@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 #33 忘记说了一点，能不能右键加入删除呀，搜出来的内容想批量删掉。

@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 你试试，看看够不够用 :-)

@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*这样，我觉得这样很方便😂

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

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

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

这个可以继承到 finder 的右上角的搜索吗？ 其实有些时候是在当前文件夹下搜索场景也蛮多的

大佬，这个能排序吗？

@kisstrnt 支持的