SmsForwarder 替代方案：Bark、ntfy、Pushover 怎么选

🇺🇸
Read in English: SmsForwarder Alternatives: Choosing Between Bark, ntfy and Pushover for Phone Notification Forwarding

抽屉最里面那台旧安卓机，很多人家里都有一台。屏幕有一道划痕，电池掉得厉害，但插上充电线还能亮。它连着家里的 WiFi，安静地躺在那儿，收着各种验证码、银行动账提醒、快递到站通知，还有运营商发来的流量余量告警。问题在于，这台手机不在你手上。你在书房用主力机，在厨房用平板，在公司开会时手机调了静音，那些短信就落在抽屉里，等你晚上想起来去看，验证码已经过期十分钟了。

于是有人装上了 SmsForwarder：旧机器负责盯着屏幕，一有短信就按规则转发出去。用了一段时间之后，会冒出一个念头，能不能换个更省心的东西？这时候搜索框里会同时跳出 Bark、ntfy、Pushover 三个名字。它们看起来都在做同一件事，把消息推到手机上，于是被当成 SmsForwarder 的替代品来比较。这个比较从第一步就偏了。

先把采集和推送拆开看

一条短信从旧安卓机跑到你手里，中间其实是两段路。第一段是采集：谁在安卓系统里拿到短信广播、来电状态、通知栏内容，谁就是采集端。第二段是推送：谁负责把这段文字送过网络，落到一台 iPhone 或者另一台安卓的通知栏里。

SmsForwarder 站在第一段。它是一个安卓应用，通过系统的短信、通话记录、通知监听权限拿到内容，再按你写的规则分发出去。它自己能对接的通道很多，钉钉群机器人、企业微信、飞书、邮箱、webhook、Telegram 机器人、Server酱、PushPlus、直接发手机短信，还有一个关键的名字：bark。也就是说，SmsForwarder 里的 bark 选项，就是把内容推给 Bark 的服务端。

Bark、ntfy、Pushover 站在第二段。它们不读你的短信，也没有安卓端的短信监听权限，它们只是「把一段文本变成手机上的通知」这件事的执行者。

想清楚这一点，替代关系就分成了三种。第一种，你嫌 SmsForwarder 太杂、只想换个更简单的采集端，那这三个都不是答案，因为它们根本采集不了短信。第二种，你对 SmsForwarder 的采集能力满意，只是不满意它默认推到钉钉群或者邮箱的方式，想让通知更即时、更安静、更像原生提醒，那 Bark、ntfy、Pushover 就是纯正的替代品。第三种，也是最常见的：保留 SmsForwarder 采集，换掉后半段的通道，两者配合着用。旧手机监听短信，Bark 把内容送到你的 iPhone 锁屏上，SmsForwarder 的一条转发规则就完成了整条链路。

多数人嘴上问的是「替代」，真正想要的其实是第三种组合。把一个全能工具拆成两件各司其职的工具，出问题时也更容易定位是哪一段断了。

三个通道各自的脾气

先说 Bark。它是一个只做 iOS 的应用，服务端和 App 都是开源的，MIT 协议，GitHub 上大约 9.4k star，走苹果的 APNs 推送通道。免费，没有付费档。它的用法极其直接，一个 GET 或 POST 请求打到 /:key/:title/:body 这样的地址，通知就出现在 iPhone 上。作者在 README 里给了自建服务端的说明，也支持加密推送，这一点对在意内容经过第三方服务器的人来说有实际价值。

Bark 最讨人喜欢的地方在细节。它支持分组，你可以让「服务器告警」和「家里的事」分成两个列表；支持自定义图标和铃声，点开通知能跳转到指定 URL。它还支持时效性通知，能在专注模式下穿透显示，以及 critical 重要警告，按文档说明可以无视静音和勿扰。call 参数能让手机重复响铃三十秒，这个功能用在「服务器挂了」或者「家里老人按了紧急按钮」这类场景上，比一条静默横幅有用得多。社区里围绕它做的周边也很多，浏览器扩展、命令行工具、GitHub Actions 集成，说明它被不少人当成了长期的私人通知管道。

局限同样明显：它只有 iOS App。你主力机是 iPhone，这事完全不是问题；你主力机是安卓，Bark 对你等于不存在。另外，它默认使用公共服务器，虽然能自建，但自建意味着你要维护一台有公网入口的机器，还要处理证书。

假设你是个用 iPhone 的人，家里那台旧安卓机专门收验证码。SmsForwarder 里填上 Bark 的 key，规则设成「包含『验证码』的短信转发」。之后你在电脑前工作，验证码直接在 iPhone 锁屏上弹出来，长按就能复制，不用起身去抽屉里翻那台旧机器。整条链路零成本，也没有任何一台服务器需要你操心。

再说 ntfy。它是三者里最「程序员向」的一个，整个产品围绕一个 HTTP 接口展开。文档里的第一个例子就很有代表性：curl -d "Backup successful" ntfy.sh/mytopic，一条命令，消息就到了订阅了这个主题的设备上。除了 curl，还有官方的 ntfy CLI，写脚本、塞进 crontab、接进 CI，都很顺手。

ntfy 的手机端覆盖比 Bark 广，安卓有 Google Play 和 F-Droid 两个渠道的 App，iOS 也有。主题不需要事先注册或者创建，随便挑个名字发过去，就自动存在了。这种「没有账号、没有后台、没有配置页面」的设计，对讨厌注册流程的人很友好，对不想把自己的手机号交给又一家服务商的人也很友好。

代价在于主题名是公开的。文档里明确提醒，任何人只要知道主题名就能订阅，所以名字要取得不容易猜到。这句话值得停下来想一秒：如果你用 sms 或者 myphone 当主题，别人猜中之后，你转发的验证码就会实时出现在他的手机上。取一个带随机串的长名字，等于把它当成一个弱口令来对待。ntfy 的文档里没有提供价格信息，公共服务器可以直接用，自建也在它的能力范围内，具体怎么部署要按官方文档走。

ntfy 适合谁？手里有一台常年开着的 NAS 或者 VPS，习惯用脚本解决问题，希望通知能从各种奇怪的角落发出来的人。比如备份脚本跑完发一条、爬虫挂了发一条、家里的树莓派温度过高发一条。这类需求用 Bark 也能做，但 ntfy 的接口形态更贴近命令行思维，自建之后数据也完全在自己手里。

最后是 Pushover。它是三者里最像「商品」的一个，有明确的定价页，有付费墙，也有对应的服务承诺。按官网 Pricing 页面的说明，个人版是按平台一次性买断，iPhone 与 iPad 算一个平台，安卓算一个，桌面算一个，每个平台 4.99 美元，买之前有三十天免费试用。同一个平台上的多台设备共享这一次购买，个人用户没有订阅费。团队版是按人按月计费，每用户每月 5 美元，包含集中管理、优先消息队列和优先支持。每个用户每月的免费发送上限是一万条，同时提供 API 和邮件网关。

这套定价结构说明它服务的是「长期稳定使用」的人。一次性付费换来的是一种心理上的确定感：不会某天醒来发现免费额度改了，也不会因为用量涨了被要求升级。多平台分别收费这点要留意，如果你 iPhone、安卓、桌面都要收通知，账要按三份算。

Pushover 的典型用户是那种不想折腾的人。他可能在一家小公司管着几台服务器，需要告警稳定送达，需要团队里几个人同时收到，最好还有人负责兜底支持。他不想自己搭服务端，也不想每个月对着一堆开源项目的 issue 页找答案。按平台各买一份，比花一个周末配置自建服务划算得多。

需要说明的是，这三者对「通知长什么样」的控制力度不一样。Bark 在 iOS 上的定制项最多，分组、图标、铃声、时效性、critical 都能调。ntfy 的核心是那个简单的 HTTP 接口，把消息送出去是第一位的。Pushover 提供的是托管服务加一套 API 和邮件网关。这个差异在简单场景里感觉不到，等你开始给不同来源的消息分配不同优先级时，就会变得明显。

放在一张表里为什么难

把这三者和 SmsForwarder 放进同一张表，本身就有点勉强，因为它们的坐标轴不一样。前面说的采集与推送是纵向的切分，而平台、价格、自建能力是横向的维度。硬凑在一张表里，容易让人误以为它们是同一层的竞品。

所以下面这张表，我刻意加了一列「能否采集短信」。这一列的作用不是评价好坏，而是让替代关系一眼可见：只有 SmsForwarder 在这一列是「能」，其余三个都是 N/A。看表的时候请把前四行当成推送通道来读，把最后一行当成采集端来读。

工具	价格 / 协议	自建	能否采集短信	适合谁
SmsForwarder	免费，BSD-2-Clause	N/A（本地安卓应用）	能，短信、来电、App 通知	有旧安卓机、需要按规则分发的安卓用户
Bark	免费，MIT	支持，需自有服务器	N/A	iPhone 主力机用户，想要精细的提醒样式
ntfy	文档未列出价格	支持	N/A	有常开服务器、习惯用脚本发消息的人
Pushover	个人每平台 4.99 美元买断，团队每用户每月 5 美元	N/A（托管服务）	N/A	愿意一次付费换稳定服务的小团队和个人

表里 Pushover 的「自建」写 N/A，是因为官网定价页描述的是一套托管服务，我没有看到自行部署服务端的说明。Bark 和 ntfy 的自建都需要你有一台能被手机访问到的机器，这不是装个软件就完事，证书、域名、进程守护都得自己管。

安全这件事，得单独说几句

SmsForwarder 有一个很多人没注意到的功能面：从 v3.0 起，它支持主动控制，可以远程发短信、查短信、查通话、查话簿、查电量。v3.3 起还加了自动任务和快捷指令。这些功能要工作，就得开一个服务端接口，而接口一旦暴露在公网上，性质就变了，它不再只是一个转发器，而是一台可以被远程指挥的安卓设备。

2026 年 10 月 24 日，项目的一次提交专门处理了这块的安全问题，修复了 CVE-2026-110618。按提交说明，修复后的服务端默认是 fail-closed 的：启动时自动生成签名密钥，远程接口默认关闭，只监听回环地址，签名密钥为空时直接拒绝请求，鉴权失败返回 401，服务端被禁用时返回 403。这一串改动指向同一个意思：以前那种「开箱就能从外网访问」的默认状态，风险是真实的。

谁该关心这件事？如果你只是用它转发短信到 Bark，压根没开过远程控制服务端，那你基本不在受影响的范围里。如果你曾经为了「在外面也能查那台旧手机收到什么」而开过这个接口，并且把它映射到了公网，那应该尽快升级到修复后的版本，并且重新检查一遍暴露面。升级只是补上默认值，暴露的端口还得你自己关。另外，README 里写明代码仅用于测试学习研究、禁止商用，隐私声明称不收集隐私数据，只在启动时向友盟发送版本信息统计，手动检查更新时发送版本号。这两条不冲突，但都值得知道：这是一个个人项目，不是一个有合规团队背书的产品。

ntfy 那边的风险则是另一种形态。它没有账号体系，安全性完全建立在「主题名没人猜得到」上面。这在自建场景下问题不大，因为服务在你自己域名的后面。用公共服务时，主题名就等同于密码，而且改名字就意味着所有订阅端都要重新设置。取名字的时候用一串随机字符，别用「family」「alarm」「sms」这类词。

Bark 的 key 也是同样的道理。URL 里的那串 key 就是凭证，谁拿到谁就能给你发通知，虽然只能发通知，但在某些场景下（比如伪装成银行提醒）也够用来骗人了。Bark 支持加密推送，对内容敏感的人可以开。

按你手上的设备来选

如果你是 iPhone 主力机，旧安卓机专门收验证码，那最省事的组合是 SmsForwarder 采集加 Bark 推送。零成本，配置十分钟，Bark 的分组能让验证码和别的通知分开，critical 和 call 参数能保证紧急消息真的把你叫醒。这条路唯一的门槛是你得接受通知经过 Bark 的公共服务器，介意的话就自建。

如果你全家都是安卓，主力机也是安卓，Bark 直接出局。这时候的选择是 SmsForwarder 直接推到 ntfy 的安卓 App，或者用 Pushover 的安卓客户端。前者免费但要自己管主题名，后者一次性 4.99 美元买断、省心。家里如果还有一台常年开着的 NAS，ntfy 自建是很自然的选择，顺带还能给别的脚本用。

如果你本来就想要自建，那问题就不在 SmsForwarder 和谁比，而在你想把哪一段握在自己手里。自建 ntfy，你控制的是推送通道；自建 Bark 服务端，你控制的也是推送通道；两者都不解决采集，采集仍然依赖那台旧安卓机上的 SmsForwarder。真想连采集都自建，路径是用 Tasker 之类的自动化工具自己写监听逻辑，工作量比装一个 App 大得多。

如果你是小团队，需要几个人同时收到告警，Pushover 的团队版官网写明提供集中管理。每用户每月 5 美元，换来的是集中管理、优先消息队列和优先支持。用自建服务也可以走类似思路，但你得自己维护，出了故障没人替你兜。

回到抽屉里那台旧手机。它不需要被替换掉，它需要的是一个靠谱的出口。SmsForwarder 负责听，Bark 或者 ntfy 负责喊，Pushover 负责在你不想管服务器的时候替你把这件事包下来。把这两段分清楚之后，「替代方案」这个问题会自己缩小成一个更具体的问句：我想换的到底是哪一段。