共计 5727 个字符，预计需要花费 15 分钟才能阅读完成。
前段时间重装了一台 MacBook，趁着从零开始的机会，我把自己这些年攒下来的应用清单重新过了一遍。过程中有个挺明显的感受：这几年 macOS 上的效率类软件几乎集体转向了订阅制，一个剪贴板管理器要按年付费，一个菜单栏整理工具卖到几十美元，再叠加 2024 年 Bartender 被悄悄转手、新东家在用户毫不知情的情况下接管了一个拥有辅助功能权限应用的那次风波，我对「装一个小工具」这件事变得越来越谨慎。最后留在新系统上的，反而大多是开源项目。
这篇文章整理六款我用了很久、并且确实每天都在用的 macOS 开源应用。它们的共同点是：源码公开、有活跃或者曾经活跃的社区、装完之后基本不用再操心，功能上也不比对应的商业软件差多少。
为什么我更愿意在 macOS 上选开源应用
这里的理由并不只是「免费」。macOS 上的效率工具有一个相当特殊的属性，就是它们几乎都需要非常高的系统权限。窗口管理工具要辅助功能权限，才能移动和改变别的应用窗口的大小；剪贴板管理器要持续读取剪贴板内容，你复制的每一段密码、每一个 Token 都会经过它；菜单栏管理工具同样要辅助功能权限，才能操作状态栏图标；系统监控工具要读取传感器数据。这些权限一旦授予，应用能看到的东西远比你想象的多。
在这个前提下，源码是否公开就不只是一个技术偏好的问题了。Bartender 那次的争议核心并不是软件本身出了什么恶意行为，而是所有权发生变更时，用户完全没有办法验证「这个拿着我全部辅助功能权限的应用，现在到底属于谁、在做什么」。开源应用至少提供了一个可审计的下限，加上 Homebrew Cask 这一层分发渠道，安装和升级都能被脚本记录下来，重装系统的时候一条命令就能还原环境。
另外一个现实的好处是可移植性。像下面要讲的 LocalSend，它同时覆盖 macOS、Windows、Linux、Android 和 iOS，这种跨平台能力在闭源的生态里通常意味着要买好几份授权，而开源项目天然就没有这个问题。
LocalSend 把 AirDrop 的体验带到所有设备上
[[LocalSend]] 目前在 GitHub 上有接近 9 万颗星，用 Flutter 编写，采用 Apache License 2.0 协议。它解决的问题非常具体：AirDrop 好用，但只在苹果生态内部好用，一旦你手里同时有 Mac、Android 手机和一台 Windows 台式机，跨设备传一个文件就突然变成了一件麻烦事，要么走微信文件传输助手压缩画质，要么翻出数据线。
LocalSend 的底层是一份公开的 LocalSend Protocol，本质上是基于 HTTP(S) 的简单 REST 协议，完全不依赖任何外部服务器，所有通信都发生在局域网内部。设备发现默认通过 UDP 组播完成，应用启动时向组播地址 224.0.0.167 的 53317 端口广播一条 JSON 公告，里面包含设备别名、协议版本、设备类型、指纹和端口等信息，局域网内其他实例收到之后会通过 TCP 回应一个注册请求。之所以选了 224.0.0.0/24 这个网段，是因为部分 Android 设备会拒绝加入其他组播组，这种细节上的取舍能看出项目在真实设备上打磨过。
传输本身默认走 HTTPS，每台设备启动时动态生成一张自签名 TLS 证书，内容是端到端加密的，不需要任何证书颁发机构参与，设备身份则用证书的 SHA-256 哈希作为指纹来识别。整个流程分成 prepare-upload 和 upload 两步，前者只发送文件元数据让接收方确认，后者才真正推送二进制数据，多个文件可以并行上传。我个人很喜欢的一个设计是反向传输模式：当对方电脑上根本没装 LocalSend 时，可以由发送方架起 HTTP 服务，接收方直接用浏览器打开 http://<发送方IP>:53317 就能下载，临时借用别人的电脑时特别方便。
实际用下来最容易踩的坑集中在网络环境上。很多路由器和几乎所有公共 Wi-Fi 都开启了 AP 隔离（客户端隔离），设备之间根本无法互相通信，这时候 LocalSend 会一直搜不到对方。另一种情况是路由器禁用了组播，此时 LocalSend 会退回到扫描局域网 IP 的暴力发现模式，速度会慢很多。遇到搜不到设备的时候，最稳的办法是在界面里手动添加对方的 IP 地址，另外记得确认 macOS 防火墙没有拦掉 53317 端口。
IINA 把 mpv 内核装进了原生的 macOS 外壳
[[IINA]] 用 Swift 编写，GPL-3.0 协议，要求 macOS 12 及以上。macOS 上看视频这件事长期处于一个尴尬的状态：系统自带的 QuickTime 格式支持极其有限，稍微冷门一点的编码就直接罢工；[[VLC]] 什么都能放，但那套跨平台 UI 放在 Mac 上总有种水土不服的违和感；而 [[mpv]] 本身足够强大，命令行和配置文件的门槛却把大部分人挡在了外面。
IINA 的思路是把 mpv 作为播放内核，外面套一层完全原生的 macOS 界面。这意味着你既能享受 mpv 那套成熟的解码能力和几乎通吃的格式支持，又能获得符合 Mac 使用习惯的交互：深色模式、画中画、Force Touch、触控板手势快进、播放列表和章节面板、在线字幕搜索，这些都是按照系统设计语言实现的。它还提供了 Safari、Chrome 和 Firefox 的浏览器扩展，网页上的视频可以直接「Open in IINA」丢过来播放。
对于愿意折腾的人，IINA 保留了 mpv 的完整配置能力，可以在偏好设置里直接编辑 mpv 的配置项和启动参数，甚至加载 mpv 的 Lua 脚本。我自己常调的是硬件解码相关的设置，在 Apple Silicon 上把解码器切到 videotoolbox 之后，播放 4K HEVC 素材时风扇明显安静了不少，续航也更好。字幕方面它支持从 OpenSubtitles 在线搜索，中文字幕的命中率一般，更常见的用法还是把 srt 或者 ass 文件直接拖进播放窗口。
需要说明的一点是，IINA 的开发节奏并不算快，1.x 版本跟进 mpv 上游的速度有时会滞后，一些极端场景下的滤镜或者音频输出行为和最新版 mpv 存在差异。但对于日常看片、看录屏、看教程这类需求，它已经稳定到几乎不需要关注版本号的程度。
Stats 用一个菜单栏换掉付费的系统监控
[[Stats]] 有超过 4 万颗星，Swift 编写，MIT 协议，版本迭代非常勤快，要求 macOS 12 及以上。这个领域的标杆是收费的 [[iStat Menus]]，功能确实完善，但对于只想在菜单栏看一眼 CPU 占用和网速的人来说，Stats 提供的东西已经绰绰有余。
它把监控内容拆成一个个可以独立开关的模块：CPU、GPU、内存、磁盘、网络、电池、传感器，还有蓝牙设备电量。每个模块的菜单栏显示样式都能单独配置，可以是纯数字、迷你折线图、柱状图或者圆环，点开之后还有更详细的面板，比如网络模块会列出当前的公网 IP、局域网 IP 和占用带宽最多的进程。传感器模块在 Apple Silicon 机器上能读到各个核心的温度和风扇转速，这在跑长时间编译任务的时候挺有参考价值。
实际使用中要注意两件事。一是菜单栏空间的争夺，模块开得越多，占的横向宽度越大，如果你的 MacBook 有刘海，很容易出现应用自己的菜单项被挤到看不见的情况，所以我一般只常驻 CPU、内存和网络三项，其余的放在展开面板里看。二是采样频率带来的开销，默认设置下 Stats 本身的资源占用很低，但如果把更新间隔调到极短，再叠加多个模块，反而会成为一个持续唤醒 CPU 的后台负担，1 秒到 3 秒的刷新间隔是比较合理的区间。
Rectangle 让窗口回到键盘的掌控之下
[[Rectangle]] 有 29784 颗星，Swift 编写，MIT 协议。它的血统来自已经停止维护的 [[Spectacle]]，作者在 LICENSE 里也明确标注了这一点。核心功能就一件事：用快捷键把窗口移动到屏幕的某个区域，左半屏、右半屏、四分之一、三分之一、最大化、居中，或者把窗口甩到另一台显示器上。
macOS 15 Sequoia 之后系统自带了窗口贴靠功能，很多人会问 Rectangle 是不是没必要了。我的答案是仍然有必要，差别主要在布局的丰富程度和快捷键的自由度上。系统贴靠提供的分屏方案比较基础，而 Rectangle 支持三分之一、三分之二、六分格这类在宽屏显示器上非常实用的布局，并且每一个动作的快捷键都可以自定义。它还有一个我用得很多的功能叫 Rectangle 的拖拽贴靠，把窗口拖到屏幕边缘或者角落会出现预览框，松手即定位，逻辑和 Windows 上的 Aero Snap 一致。
安装之后第一件事是去「系统设置 – 隐私与安全性 – 辅助功能」里授权，没有这个权限它无法操作其他应用的窗口。如果你在 macOS 15 及更高版本上使用，建议把系统自带贴靠的快捷键关掉，否则两套快捷键会打架，出现按下组合键后窗口先被系统摆一次、再被 Rectangle 摆一次的抖动。另外 Rectangle 还有一个付费的 Pro 版本，提供更复杂的自定义布局和应用级规则，但免费版对绝大多数人来说已经够用，我用了几年也没有产生升级的需求。
Maccy 把复制过的内容都找回来
[[Maccy]] Swift 编写，MIT 协议，需要 macOS 14 及以上。剪贴板历史属于那种「没用过觉得没必要，用过之后回不去」的功能，尤其是写代码或者写文章的时候，经常需要在几段内容之间来回粘贴，系统只保留最后一次复制的内容实在太局促。
Maccy 的定位是极致轻量：一个默认的全局快捷键呼出搜索框，直接输入关键词就能在历史记录里模糊匹配，回车即粘贴，整个过程不需要碰鼠标。它支持把常用条目固定（pin）在列表顶部，比如自己的邮箱地址、常用的命令片段。相比订阅制的 [[Paste]] 或者 [[PastePal]]，它没有花哨的多设备同步和分类面板，但也正因为如此，它的内存占用和启动速度都非常克制。
安全方面有个细节值得一提：Maccy 会遵守 org.nspasteboard.ConcealedType 这个剪贴板标记，主流的密码管理器在复制密码时会打上这个标记，Maccy 看到之后就不会把内容存进历史。不过并不是所有应用都规范地使用这个标记，所以如果你有某些确定不希望被记录的应用，最好在偏好设置里把它们加入忽略列表。另外默认保存的历史条数是有限的，需要更长的历史就自己调高上限，但要意识到这些内容是存在本地数据库里的，条数越多，意外泄露时的暴露面也越大。
Ice 整理杂乱的菜单栏，但要留意它的维护状态
[[Ice]] 有接近 3 万颗星，Swift 编写，GPL-3.0 协议。它做的事情是把菜单栏图标分成显示、隐藏、始终隐藏三个区域，平时只露出你真正需要的那几个，其余的折叠起来，点击分隔符或者按快捷键才展开。对于有刘海的 MacBook 来说这几乎是刚需，图标一多，靠近刘海的那些就会被直接吞掉，连点都点不到。
Ice 之所以在 2024 年迅速积累了这么多 star，很大程度上是承接了 Bartender 那次信任危机之后流失的用户。它的功能覆盖了 Bartender 的主要场景，交互也做得相当克制，配置项不多但都在点子上，比如可以设置某个图标在有新通知时自动短暂显形。
这里必须诚实地说明一个情况：Ice 目前的维护状态并不理想。最新的正式 release 是 2024 年 10 月发布的 0.11.12，主分支最后一次提交停留在 2025 年 9 月，仓库里积压了 400 多个未关闭的 issue。项目没有被归档，作者也没有宣布停止维护，但客观上更新已经明显放缓，在较新的 macOS 版本上可能会遇到图标错位、展开动画卡顿之类的兼容问题。如果你在意长期可用性，可以同时了解一下 Hidden Bar 这类更简单的开源替代，或者接受商业方案。装 Ice 之前建议先确认一下当前 macOS 版本在 issue 列表里的反馈情况。
用一条命令把它们装完
上面六款应用都在 Homebrew Cask 里，重装系统之后一条命令就能全部装好：
brew install --cask localsend iina stats rectangle maccy jordanbaird-ice
这里有个容易踩的小坑：Ice 的 cask 名字不是直觉上的 ice，而是 jordanbaird-ice，直接写 ice 会提示找不到。如果你和我一样习惯用 [[Homebrew]] Bundle 管理环境，把这几行写进 Brewfile 会更省事，配合 brew bundle dump 定期导出，换机时的应用还原基本就是无脑执行。
装完之后有几个权限需要一次性处理掉，否则应用看起来装好了却不工作。Rectangle 和 Ice 都需要「辅助功能」权限，Maccy 需要在首次弹窗时允许监听剪贴板，Stats 的传感器模块在部分机型上需要额外确认，LocalSend 第一次运行时会请求本地网络访问权限，这个如果不小心点了拒绝，之后就再也搜不到设备了，需要去「隐私与安全性 – 本地网络」里手动打开。我的经验是装完之后直接把这几个权限页面挨个点一遍，比之后遇到问题再回头排查省事得多。
还有一点关于升级。Cask 安装的应用可以用 brew upgrade --cask 统一升级，但部分应用自身也带了内置的自动更新（比如 Stats 和 Rectangle），两套机制同时工作时偶尔会出现版本号对不上的情况，表现为 Homebrew 认为需要升级但应用其实已经是最新的。遇到这种情况用 brew upgrade --cask --greedy 重新对齐一次即可，不影响使用，只是看着有点别扭。
最后
把这六款应用放在一起看，会发现它们覆盖的其实是使用 macOS 时最高频、最基础的几个动作：传文件、看视频、看状态、摆窗口、找剪贴板、理菜单栏。这些需求本身没有任何技术含量，却因为系统自带的能力总差那么一点，长期以来养活了一大批收费软件。开源社区在这些位置上给出了完成度足够高的答案，而且它们的体积和资源占用普遍比商业版更克制。
我并不认为开源就一定优于付费，Ice 的维护现状就是一个很好的提醒：开源项目的持续性依赖维护者的个人投入，热度可以在几个月内积累几万颗星，也可以在下一年悄无声息地放缓。所以我的选择标准不是「是不是开源」，而是「出问题时我有没有退路」，源码公开、协议宽松、有 Homebrew 这样的分发渠道，这三件事加起来才构成了真正的退路。
