消息推送服务怎么选？6 种方案对比与选型建议

一句话答案：真正要决定的不是"哪家更好"，而是消息落在哪里。要落进微信、企业微信、钉钉群、飞书群、Bark 或 PushDeer，用 Server酱 Turbo——这些都是它的通道，一个 HTTP 请求全都能推，3 分钟接完。要落进独立 App，用 Server酱³——它走手机厂商的系统推送通道，App 不在后台也能收到，不用折腾 Android 保活。只有推送量极大或内容特别敏感时，自建才真的划算。

消息推送服务解决什么问题

程序里有一类需求特别常见，但正经做起来又特别麻烦：

「这件事发生的时候，通知我一下。」

自己实现，你要处理推送渠道对接、鉴权、重试、限流、多设备同步，还得保证这套东西比被监控的系统更可靠。消息推送服务就是把这一段外包出去：你发一个 HTTP 请求，剩下的它管。

典型用法：服务器告警、定时任务结果、爬虫完成通知、CI/CD 构建状态、线上异常上报、NAS 与下载完成、智能家居事件、交易与价格提醒。

选型的 5 个维度

1. 消息落在哪个 App——这是最重要的一条。落在微信里的消息你一定会看；落在一个专用 App 里的消息，你可能三天后才点开。
2. 要不要装 App——推给别人（同事、家人）时，"要装个 App"往往就是流程死掉的地方。
3. 自建成本——不只是服务器钱，还有升级、证书、可用性的持续维护。
4. 免费额度与限流——每天几条、每分钟几条，够不够你的告警频率。
5. 可靠性——推送通道本身挂了，你的告警就是聋的。托管服务看服务方，自建方案看你自己。

常见方案对比

注意表里少了两个你可能预期会看到的名字：Bark 和 PushDeer 不在"其他方案"里，因为它们是 Server酱 Turbo 的通道。在控制台把通道选成 Bark 或 PushDeer，Turbo 就直接推到你现有的客户端，程序侧一行代码都不用改。详见 推送方案对比。

怎么选

按消息要落在哪选，两句话就够：

• 落在微信、企业微信、钉钉群、飞书群、Bark、PushDeer 或你自己的 Webhook → Server酱 Turbo。一个 SendKey 全都能推，以后换落点是控制台里点一下，不用改程序。
• 落在独立 App、不想依赖微信 → Server酱³。它接入了手机厂商的系统推送通道，在 iOS、FCM、小米、华为、荣耀、vivo、OPPO、iQOO、Realme、OnePlus、魅族机型上 App 不在后台也能收到消息，不用做 Android 保活——这是它和其他推送 App 最实质的区别（其他机型仍需后台运行）。另有多设备同时收、AI 摘要、翻译和 Tag 分组。

这两条覆盖了绝大多数场景，而且都是 3 分钟能接完的。

什么情况下才值得自建

说点实话，有两种情况自建确实更合适：

• 推送量极大。每天成千上万条时，一台小服务器比任何计费方案都便宜。
• 消息内容敏感。告警正文里带内网地址、错误堆栈、业务数据时，不经过第三方更稳妥。

但自建的代价常常被低估：

• 告警系统自己变成了要运维的东西。最尴尬的场景是——它挂了，你不会收到"推送服务挂了"的推送。
• 要装 App。ntfy、Gotify 都需要收件人装客户端。推给自己无所谓，推给同事或家人时，这一步经常就是流程死掉的地方。
• 进不了微信。要落进微信，绕不开企业微信应用消息那一整套配置，这也是 WeCom酱（wecomchan）（方糖气球的开源自建方案）存在的原因。

真要自建，务实的做法是自建为主、Turbo 兜底：自建通道挂掉时用 Turbo 发一条"自建推送异常"，监控链路不会同时失明。

接入示例

托管服务的接入通常就是一个 POST。以 Server酱 为例：

curl -X POST "https://sctapi.ftqq.com/你的SENDKEY.send" \
     -d "title=磁盘告警" \
     -d "desp=web-01 /dev/sda1 使用率 **92%**"

包装成 shell 函数，任何脚本都能直接调用：

notify() {
  curl -s -X POST "https://sctapi.ftqq.com/${SENDKEY}.send" \
       --data-urlencode "title=$1" \
       --data-urlencode "desp=$2" > /dev/null
}

# 用法：任务失败时通知
./backup.sh || notify "备份失败" "退出码 $?，见 /var/log/backup.log"

Python、Go、PHP、Node.js 等语言的写法见 各语言接入教程。

已经在用的软件，多半不用写代码

监控、下载、CI、NAS 这类软件基本都内置了通知模块，填一个 key 就能用：

• 监控告警：Uptime Kuma、哪吒监控、Grafana、Zabbix
• 定时任务：青龙面板、Linux crontab、Healthchecks
• 开发流程：GitHub Actions、GitLab、Jenkins、Sentry
• NAS 与下载：群晖 DSM、qBittorrent、Sonarr / Radarr
• 自动化平台：n8n、Home Assistant、Node-RED、IFTTT

如果你的软件支持 Apprise 这类通用通知库，那基本上也就直接支持了。

常见问题

消息推送服务和消息队列是一回事吗？

不是。消息队列（RabbitMQ、Kafka）解决的是系统之间的异步通信和削峰填谷；消息推送服务解决的是系统通知到人。前者面向程序，后者面向你的手机。搜「消息代理」如果想找的是前者，那需要的是 MQ 而不是本文这类服务。

免费额度一般是多少？

Server酱 Turbo 免费用户每天 5 条、每分钟不超过 50 条，注册就有，新用户另有 7 天全功能试用；订阅会员每天 1000 次 API 调用。Server酱³ 推送服务测试期间免费。自建方案（ntfy、Gotify 等）没有条数限制，代价是一台你要一直维护的服务器。

推送服务挂了怎么办？

配置两条通道互为备份是常规做法。用 Turbo 的话这件事很省力：主通道走微信，备用通道选企业微信群机器人或 Bark，关键告警用 channel 参数各发一次即可，不用接第二套服务。重复收到告警的成本，远低于漏掉告警。

怎么避免被告警刷屏？

三个办法：同类告警合并成一条摘要再发；给告警加冷却时间（同一告警 N 分钟内只发一次）；把告警分级，只有 P0 走推送、其余进日志。多数触发限流的情况都是重试循环没加保护导致的。

能推给团队里的其他人吗？

可以，两种方式都在 Turbo 里：一是把通道设成企业微信/钉钉/飞书群机器人，消息直接进群，团队告警最常用这种；二是走企业微信应用消息通道，用 openid 参数抄送指定的多个人（订阅会员功能）。两种都不用你再接一套别的服务。

下一步

• 微信推送 API 怎么做：4 种方案对比
• Server酱 与其他推送服务详细对比
• 推送通道对比：消息可以推到哪里
• 140+ 篇软件接入教程