一、解决什么痛点：一条 curl 把消息推到手机
服务器、脚本、智能家居、CI 流水线想给手机发条通知，传统方案要么接厂商推送（注册 App、审配置、走 SDK），要么发邮件再等推送中转，链路又长又麻烦。ntfy（binwiederhier/ntfy，Apache-2.0，Go 编写）的思路是把这事压到最薄：一条 HTTP 请求把消息发出去，手机订阅一下就收，零注册、零费用、零 SDK。
curl -d "构建完成 ✅" ntfy.sh/mysecrettopic普通人连服务都不用搭——直接用公共实例 ntfy.sh，换个自己没人猜得到的 topic 名就能玩明白；想完全自主再自托管。这就是它 3.4 万星的起点：门槛低到「会 curl 就会用」。
二、自托管的硬件门槛，以及最容易翻车的两处
要自己跑一套（推荐，尤其是敏感信息），一台常驻的小机器就够：树莓派、家里的小主机、便宜云服务器都行，要求就两条——有公网地址、有一个域名。
- HTTPS 证书：Android 端订阅要求 HTTPS，证书配不好（自签 / 域名不对 / 到期没续）推送直接静默失败
- Android 后台保活：通知走 ntfy 的 Android app 常驻订阅，国产 ROM 杀掉后台之后收不到推送是最常见的「我明明配好了为什么没响」
服务端本身极轻（Go 单二进制 + SQLite），Docker 一行 ntfy serve 就起来，运维难度主要不在这，而在上面这两条。
三、核心原理：基于 HTTP 的发布-订阅
ntfy 本质是一个极简 pub-sub 通知服务：
- 订阅侧：客户端（App / 网页 / 另一个进程）
GET订阅某个 topic，服务端把这个连接挂起 - 发布侧：另一端用
POST/PUT往同一个 topic 发消息，服务端立即推给所有订阅者 - 传输层：长连接用 WebSocket 和 SSE（Server-Sent Events）实现实时下发，普通 HTTP 也能工作
- 消息体：不只是文本——图片、文件都能推，手机上直接看
没有账号体系、没有复杂路由，topic 就是地址。这种「薄」既是优点（好理解、好调试、好接脚本），也是自托管时必须自己补鉴权的原因（见下节）。
四、能不能上生产：能，但有边界
大量运维把它用在生产环境：监控告警（Uptime Kuma / Healthchecks 类）、CI/CD 跑完通知、NAS 事件提醒（下载完 / 硬盘告警）。但边界很清楚：
- 公共实例 ntfy.sh 别发敏感信息——topic 名即地址，猜得到就收得到，且你有速率限制和保留时长限制
- 自托管必须补三样：开鉴权（access key / 每 topic 密码）、强制 HTTPS、做好访问控制
- 不想自托管也不想要完全免费档的话，官方 ntfy Pro 最低 $5/月，适合不折腾运维但想要专属 topic 的场景
五、横向对比：ntfy / Gotify / Pushover
| 项目 | 特点 | 适合谁 |
|---|---|---|
| ntfy | 开源跨平台、HTTP 原生、自带文件推送、可自托管、免费公共实例 | 脚本 / 运维 / 完全自主 |
| Gotify | 更轻量的自托管推送（Docker 一键），生态没这么全，没有公共免费实例 | 纯自托管、想自己完全掌控 |
| Pushover | 体验最顺滑（App 打磨好、桌面/手机全平台），但闭源收费（免费档有限流） | 不想碰运维、愿意付费 |
选型一句话：想开箱即用选 Pushover，想完全自主选 ntfy，只想自托管个最小推送选 Gotify。综合来看 ntfy 最均衡——开源、跨平台、一条 curl 接入、还能推文件，3.4 万星不是白来的。
项目地址：github.com/binwiederhier/ntfy · 公共服务：ntfy.sh · 星标 34,152（截至 2026-09-11 实查，最新 release v2.28.0）· 配套客户端：ntfy-android / ntfy-ios