Tinycast vs Raycast 横评兼容 114/147 个命令之外差距还剩什么【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast完全原生运行 Raycast 扩展——这是 Tinycast 在 README 里最醒目、也最容易引起质疑的一句宣传。一个体积不足百 MB、零第三方依赖、连 Electron 都不用的启动器凭什么直接执行 Raycast 的扩展2026 年 9 月的一篇社区实测给出了量化答案37 个已装扩展中 32 个可完整渲染147 个 view 命令中 114 个正常运行。数字之外这篇文章要回答三个问题兼容是怎么做到的、硬指标内存/权限/遥测上两者差多少、以及那些没兼容上的东西里有哪些才是 Raycast 真正的护城河。兼容面横评114/147 与 32/37 是怎么测出来的先看数字的出处。仓库文档 docs/features/extensions.md 明确记载了测量口径以开发机上真实 Raycast 中安装的 37 个扩展为基准32 个扩展、114/147 个 view 命令可启动并渲染。换算下来是 86.5% 的扩展、77.6% 的命令。更重要的是这个测量可以随时复现——Scripts/raycast-runtime/test.mjs dir在 Node 的vm上下文里驱动运行时、打印渲染树Scripts/run-tests.sh ext-test则跑真实的 Swift 引擎JavaScriptCore两条路径都直接读取真实扩展的预构建 bundle。兼容不是跑通几个 demo而是一整套取舍。Raycast 扩展的命令本质上是单个预构建 CommonJS 文件esbuild 把依赖内联只把react、react/jsx-runtime、raycast/api和 Node 内建模块保持 external。Tinycast 恰好补上这四个缺口Tinycast/Resources/RaycastRuntime.generated.js约 200 KBminified包含 React 19 react-reconciler raycast/apishim Node/Web polyfill由 Scripts/raycast-runtime 下的源码构建并提交入库。运行时跑在系统自带的 JavaScriptCore 上Swift 侧拿到的是 JSON 渲染树UI 全部用原生 SwiftUI/AppKit 画出来——没有浏览器、没有 Node、没有进程内嵌的另一套 JS 引擎。组件与 API 覆盖面在文档里有完整的清单List/Grid/Detail/Form/ActionPanel全家族及其子组件Clipboard、LocalStorage、Cache、environment、getPreferenceValues、showToast、confirmAlert、open、trash、getSelectedText、launchCommand等 API连废弃别名ActionPanel.Item、CopyToClipboardAction都保留——因为存量 bundle 还在用。Node 侧则是一份相当厚实的 shimpath、fs含fs/promises、流式读写、os、child_process、crypto哈希/HMAC/PBKDF2/AES、zlib、http/https、stream、url、querystring、assert、timers等真实实现加上net/tls/http2这类仅引用可加载、调用即抛错的惰性 stub。几个细节尤其见工程功力dgram的 UDP socket 不碰网络只是把 mDNS 查询解码后转给系统getaddrinfo解析.local名字Home Assistant 默认地址homeassistant.local因此可用ws库的握手走http.requestshim 返回一条由原生URLSessionWebSocketTask重加 RFC 6455 帧的 socketWebAssembly 的compile/instantiate通过 JavaScriptCore 的同步构造器实现让 sql.js、Zotero 这类扩展能跑起来。兼容边界的诚实程度是这次横评里比覆盖率更值得记录的一点。docs/features/extensions.md 中unsupported的实现是直接Promise.reject(new Error(… not supported in Tinycast extensions yet))见 Scripts/raycast-runtime/src/api/system.js——所有缺口都明确报错绝不静默降级。比如getFrontmostBrowserTab、net/tls的实际调用、fs.watch、process.chdir、process.exit都抛带有明确说明的异常。这意味着用户拿到的是一个可诊断、可验证的兼容边界能用就是能用不能用会告诉你为什么。内存、权限、遥测硬指标对比如果说兼容面是Tinycast 想要追上 Raycast硬指标就是它刻意拉开差距的地方。内存。README 的第一句话就是 under 100 MB of RAMCONTRIBUTING.md 把 RAM under 100 MB, always 列为对每个 PR 的硬约束并且补充了没有功能值得突破这个预算。社区实测给出的数字是常驻内存约 72.6 MB。这背后是一整套设计决策Swift 6 AppKit/SwiftUI、零第三方依赖、无 Electron。运行时机制文档里甚至写明了唯一的一次性成本a running command holds a JavaScript engine in memory until you leave it, which is the one standing cost this app has——即运行扩展命令期间的那一个 JSContext是这款应用唯一的常驻负担。即便在扩展这条最重的链路上也保留了同一时刻最多两个命令并发的不变量面板与后台no-view刷新共享一个运行时前台启动优先抢占后台刷新菜单命令走独立的串行通道。权限。Raycast 为了文件搜索、剪贴板等能力会索取一长串权限Tinycast 的策略是少要、晚要、按需要。文件搜索完全基于系统 Spotlight 索引查询通过MDQuery走 Spotlight 元数据只读kMDItemPath不建私有索引、不记录历史、不扫描磁盘——docs/features/file-search.md 的不变量原话是 Tinycast asks for no file permission隐藏路径和应用 bundle 内容在结构上被过滤不需要全盘访问权限。辅助功能Accessibility只在需要粘贴文本或展开片段时请求这是唯一必备的权限。扩展功能本身是默认关闭的开关——关闭时不扫描目录、不发布启动器行、不存在 JSContext开启前要二次确认因为启用即同意运行第三方代码。AI 同样是off out of the box关闭状态下不创建历史数据库、不启动任何辅助进程。备份文件还有一层安全设计授予能力的开关如片段监听、运行 Shell 命令永远不会随备份迁移API 密钥只进 Keychain.tinycast里不允许出现任何绝对路径。遥测。README 直接写了 no telemetry。考虑到这是一款 AGPL-3.0 的开源应用这个承诺是可以被审计的仓库里没有任何分析 SDK 依赖应用自身的数据流剪贴板、搜索词、热键都留在本地。作为对比Raycast 的免费层与 Pro 层依赖其云端服务与账号体系遥测与数据回传是其商业模式的一部分——这不是道德判断而是两种产品在隐私透明度上的结构性差异。差距与不可替代项什么时候仍该用 Raycast114/147 之外的那 33 个命令恰恰是问题最有价值的部分。docs/features/extensions.md 的 What isnt supported yet 表格给出了明确的归因缺口原因AI、BrowserExtension、WindowManagement三个 Raycast 服务在 Tinycast 没有本地等价物导入可用调用即抛明确错误证书不受 macOS 信任的 WebSocketrejectUnauthorized: false被忽略URLSession 始终校验证书链中止已发出的fetchAbortSignal完整含timeout/abort/any但请求本身仍会跑完——信号不跨桥交互式spawnstdinstdout/stderr 可流式但 stdin 只在子进程启动时写入一次net/tls、流式 HTTP没有原始 socket 桥http.request一次返回完整响应体SSE、网络级进度均不可达tools/AI 扩展入口未暴露这张表值得逐条读。AI、BrowserExtension、WindowManagement是 Raycast 的专有服务而非 API——它们没有独立的扩展包可下载而是平台内置能力。Tinycast 对它们的回答是没有本地等价物调用抛错但注意这个等价物正在被原生功能补齐窗口管理本身就是 Tinycast 的内建特性34 个命令含分屏、四等分、Spaces 切换AI 则是它自己的完整功能线Quick AI 面板 AI Chat 窗口 MCP 工具调用支持通过 OpenAI 兼容 API 或已装 AI 账号接入。也就是说这两块缺口对普通用户是平移而非损失——只是扩展里写的AI.ask()不会有人替你翻译成 Tinycast 的调用。什么时候仍该留在 Raycast结论可以收紧到几条硬场景重度依赖 Raycast AI 与工具生态的用户。Raycast 的 AI 与数千个扩展深度绑定tools/这类 AI 扩展入口 Tinycast 尚未暴露Tinycast 的原生 AI 虽支持 MCP但工具集规模不在一个量级。依赖被点名的缺口扩展浏览器标签控制getFrontmostBrowserTab直接抛错、依赖原始 TCP/TLS socket 或 SSE 流式数据、交互式 stdin 的扩展目前在 Tinycast 上跑不起来。需要 Raycast 云服务/团队功能/跨平台的用户。Tinycast 仅支持 macOS 26是纯本地单机应用Raycast 的账号同步、Pro 功能与多平台未来不在对比范畴内。在乎性能但预算也包含全家桶体验的用户Tinycast 的 72.6 MB 常驻与 Raycast 相对重得多的运行时是真实差距但 Raycast 的成熟度、商店规模与第三方生态密度短期仍是单点优势。Tinycast 对这次横评最有价值的部分不是那 77.6% 的兼容率而是它把兼容边界做成了可复现、可审计、可报错的工程数字由Scripts/raycast-runtime/test.mjs和Scripts/run-tests.sh ext-test支撑缺口由源码里的unsupported()与文档表格逐条声明性能由 CONTRIBUTING 的 100 MB 硬约束守护。换句话说Tinycast 不是另一个 Raycast 的免费平替而是把 Raycast 的扩展生态当成了可复用的开放标准——然后在自己更轻、更私密、更透明的底座上重新实现它。差距还剩什么剩下的是 Raycast 的专有服务而不是扩展 API 本身。【免费下载链接】tinycastTinycast — a tiny, fully native macOS launcher, hotkeys, and clipboard history.项目地址: https://gitcode.com/GitHub_Trending/ti/tinycast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考