不给全盘权限也能搜文件：Tinycast 的 Spotlight 白名单 vs 传统全盘索引

不给全盘权限也能搜文件Tinycast 的 Spotlight 白名单 vs 传统全盘索引【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast在 macOS 生态里文件搜索与全盘权限几乎被绑定为同一件事多数启动器、搜索工具想要覆盖整个文件系统就得向用户索取「完全磁盘访问权限」Full Disk Access然后自建一套私有索引——扫描目录树、维护 watcher、缓存元数据。授权范围大、后台动作多隐私与性能的账怎么算都难看。开源原生启动器 Tinycast 提供了另一条路它的文件搜索功能Search Files完全基于系统 Spotlight 索引采用白名单式搜索范围Scopes不扫盘、不建私索引、不记录历史全程只读 Spotlight 元数据。这篇文章不评价这个方案更好而是把两套机制的实现差异、隐私收益与覆盖度边界逐层摊开讲清楚。机制对比白名单 Scopes vs 全盘索引先看传统方案的典型链路授予 Full Disk Access → 工具后台扫描目录树 → 建立自有索引/缓存 → 输入时查自己的索引。这意味着该工具拥有了读取你所有文件的权限并且常驻后台维护索引状态。Tinycast 把这条链路整个砍掉了。FileSearchScope与FileSearchPolicy定义了搜索范围是什么意思// Tinycast/Features/FileSearch/Model/FileSearchPolicy.swift struct FileSearchPolicy: Sendable, Equatable { let homeDirectory: URL /// Home is held apart because ~/Library can never be a scope, so it is expanded. let directRoots: [URL] let includesHome: Bool let ignore: FileSearchIgnoreList }默认范围只有一条[~]home 目录。用户可以在设置面板里追加任意目录但有两件事被写死~/Library永远不会被自动纳入范围——home 会展开成它的可见子目录外加Library/CloudStorage与当前 iCloud Drive 根目录隐藏路径与.app应用包内容属于结构性排除任何用户设置都无法重新放行。真正执行搜索的是FileSearchService它把范围交给系统级 API// Tinycast/Features/FileSearch/Service/FileSearchService.swift guard let query MDQueryCreate(nil, expression as CFString, nil, stamp.map { [$0] as CFArray }) else { throw Failure.couldNotCreateQuery } MDQuerySetSearchScope(query, scopes as CFArray, 0) MDQuerySetMaxCount(query, FileSearchQuery.candidateLimit)MDQuerySetSearchScope把 scope 列表交给 SpotlightMDQuerySetMaxCount把候选上限钉死在 1,000 条。扫描磁盘目录树的工作发生在系统 Spotlight 索引服务内部Tinycast 自己从不遍历文件系统——它只是向系统查询然后把结果读回来。查询表达式同样暴露了只搜文件名的设计。FileSearchQuery.expression把每个输入词编译成一条kMDItemFSName *term*cd子句用 AND 连接因此annual report要求文件名同时包含两个词但不要求相邻或按顺序// Tinycast/Features/FileSearch/Model/FileSearchQuery.swift let matches terms.map { kMDItemFSName \*\(escape($0))*\cd } // Excluding in the predicate keeps ignored files from consuming the candidate cap. let excludes exclusions.map { kMDItemFSName ! \\(escapeGlob($0))\cd } let types filter.spotlightClause.map { [$0] } ?? [] return (matches types excludes).joined(separator: )数据流是全链路可追踪的Spotlight 同步返回最多 1,000 个候选 → 结构性过滤隐藏路径、应用包→ 忽略列表 →FuzzyMatch模糊打分 → 最多发布 200 行。这里的性能取舍很明确——kMDItemPath是 MDQuery 免费带回的唯一属性其他每个属性都是一次约半毫秒的元数据抓取旧版对上千候选抓内容类型要花整整一秒重写后每行只做一次resourceValues状态读取。项目文档docs/features/file-search.md给出的 2026-09-12 实测基线是空屏最近列表重复 41ms / 冷启动 184msa、e、swift、pdf、project等查询首跑 88–397ms、重复中位数 54–107ms对比 2026-08-11 抓全属性时的 191–668ms 是数量级差别。而忽略模式匹配几乎不占时间——同样的查询加五条自定义规则后第二遍结果仅慢几毫秒。隐私收益零缓存、不留历史、只读元数据白名单机制带来的是可数、可验证的隐私承诺。项目把不做什么写进了不变量invariants不建任何内容索引没有私有索引、没有历史、没有查询缓存、没有目录 watcher、没有搜索数据落盘空屏的 Recently Used 也是一次 Spotlight 查询最近列表读的是系统自己的kMDItemLastUsedDate30 天窗口与kMDItemFSContentChangeDate3 天窗口而不是 Tinycast 记录的任何东西只在你搜索的那一刻工作设置面板里开关的副标题写得直白——Uses the Spotlight index, only when you searchTinycast/Features/FileSearch/Settings/FileSearchSettingsView.swift。没有输入就没有任何 Spotlight 活动默认关闭fileSearchEnabled为假时既没有入口命令也没有任何 Spotlight 工作全局快捷键直接 no-op不索取任何文件权限Spotlight 或 TCC 的遗漏只会让结果集变薄绝不会弹出一个 Full Disk Access 授权请求。这几点在代码里都能对号入座。开关关闭时FileSearchCoordinator.applyEnabled()把命令从启动器移除并取消会话最近列表的实现是两条按时间戳排序的 Spotlight 查询合并后取前 20 行Tinycast/Features/FileSearch/Service/FileSearchService.swiftfor stamp in FileSearchQuery.RecentStamp.allCases { let expression FileSearchQuery.recentExpression( stamp: stamp, excluding: exclusions, filter: filter) // Only the head of a sorted list can reach the merged one, so only it is worth dating. for (path, date) in try spotlightPaths( expression: expression, scopes: scopes, sortedBy: stamp.rawValue as CFString, dating: limit) ... }忽略列表同样是隐私而不持久化的设计。内置六条规则——node_modules、DerivedData、build、dist、target、Pods——编译进二进制永不写入偏好因此也无法被关闭用户自加的规则才存入fileSearchIgnorePatternsTinycast/Features/FileSearch/Model/FileSearchIgnoreList.swift。忽略规则分三个桶无斜杠无通配符的名字走Set精确匹配无斜杠带通配符的走fnmatch匹配任意路径分量含斜杠的走整路径fnmatchFNM_CASEFOLD开启、刻意不开FNM_PATHNAME让*可以跨/。有意思的是纯*名字 glob 会被推回 Spotlight 谓词kMDItemFSName ! …cd让被忽略的文件根本不占 1,000 条候选额度——因为?和[Spotlight 只当字面量kMDItemPath又不可查询路径类 glob 只能留在本地匹配。顺带一提备份迁移也不携带权限导入设置不会授予任何文件权限或后台访问见 docs/features/file-search.md 的 Invocation 一节。搜索覆盖度的边界与适用人群白名单 系统索引不是免费的午餐它有一组明确的边界值得逐条说清只搜文件名不搜内容。所有查询都是kMDItemFSName子句正文内容、标签、评论一概不参与。需要搜文件正文的场景这条路走不通——但反过来这也正是没有私有内容索引这句话成立的原因。只覆盖 Spotlight 已索引的位置。搜索范围受 scope 列表约束且 home 展开只覆盖可见子目录与云盘根~/Library不进自动范围。如果你手动把某个~/Library下的目录加进 scope那按你的意图来——FileSearchPolicy会把home 展开与原样交给 Spotlight严格分开。结构性排除不可协商。隐藏路径与.app包内容在FileSearchQuery.isExcludedPath里做结构性过滤任何设置项都无法重新放行。它们不是忽略规则而是让这个功能免权限成立的前提。空列表是有意的空。清空全部 scope 后搜索为空而不会回退到 home——FileSearchScope的注释写得很明确清除列表是刻意选择不是未设置。结果有明确上限。1,000 候选、200 结果、最近列表 20 行。配合类型过滤器All Types / Folders / Documents / Images / Audio / Videos / Archives在查询谓词层就排除类型kMDItemContentTypeTree子句窄化过滤是重新执行同样关键词的查询而不是在一组已被 200 行截断的结果上做二次筛选——这一点由FileSearchSession以查询过滤器为键去重与版本校验保证Tinycast/Features/FileSearch/Service/FileSearchSession.swift。把这些边界叠加起来适用人群其实很清楚隐私敏感用户——不愿为搜文件交出全盘读取权限能接受只搜文件名和系统已索引区域开发者——默认忽略node_modules/DerivedData/build/target等噪音目录名字 glob 还能推到 Spotlight 端过滤避免搜一个 src 出来八百个 node_modules低频找文件、偏好零后台常驻的人——搜索完全按需发生不用时系统里没有任何索引维护进程需要全文内容搜索、需要覆盖隐藏目录、需要跨所有外部卷的用户则应该留在 Spotlight 原生或传统全盘索引方案。这本质上是一次机制层面的取舍把我能读你所有文件换成我只问你允许我问的目录而且只问系统索引。Tinycast 用白名单 Scope 加零缓存证明了这条路在 macOS 上走得通——代价是覆盖度边界清晰收益是搜索行为可以被完整审计。对于把隐私当作第一优先级、又要保留快速文件检索能力的用户这是一个值得认真考虑的平衡点。输出文章 输出文章不给全盘权限也能搜文件Tinycast 的 Spotlight 白名单 vs 传统全盘索引在 macOS 生态里文件搜索与全盘权限几乎被绑定为同一件事多数启动器、搜索工具想要覆盖整个文件系统就得向用户索取「完全磁盘访问权限」Full Disk Access然后自建一套私有索引——扫描目录树、维护 watcher、缓存元数据。授权范围大、后台动作多隐私与性能的账怎么算都难看。开源原生启动器 Tinycast 提供了另一条路它的文件搜索功能Search Files完全基于系统 Spotlight 索引采用白名单式搜索范围Scopes不扫盘、不建私索引、不记录历史全程只读 Spotlight 元数据。这篇文章不评价这个方案更好而是把两套机制的实现差异、隐私收益与覆盖度边界逐层摊开讲清楚。【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考