--- title: "你手机收到的消息通知，其实不是 App 发的" description: "解析手机推送通知的系统机制：所有 App 的通知都经苹果 APNs 或谷歌 FCM 中转以省电，并介绍 Server 酱、ntfy 等开发者自建推送工具。" date: 2026-06-06T02:00:00Z canonical: https://xiaobox.github.io/p/2026-06-06-ni-shou-ji-shou-dao-de-xiao-xi-tong-zhi-qi-shi-bu-shi-app-fa-de/ author: 小盒子 categories: ["技术"] tags: [null] license: CC BY-NC-SA 4.0 license_url: https://creativecommons.org/licenses/by-nc-sa/4.0/ --- # 你手机收到的消息通知，其实不是 App 发的 ![推送通知的系统中转路径示意图](https://xiaobox-public-images.oss-cn-beijing.aliyuncs.com/images/push-notification-cover.png) 前两天我出差，飞机落地关飞行模式，手机一亮屏，叮叮叮叮叮叮叮。十几条微信、三封邮件、两条银行扣款提醒、一个菜鸟驿站的取件码、外加拼多多跟我说「你浏览过的商品降价了」。 我寻思了一下我没寻思明白。 我在天上飞了两个小时。手机关了飞行模式才连上网。那这些消息，到底是什么时候到的？ 如果是我连上网以后 App 才去服务器拉取的，那不可能这么快。几乎是飞行模式关掉的瞬间，十几条通知同时弹出来。 如果是在我关掉飞行模式之前就已经在手机里了，那更不对。我没网，消息是怎么穿过空气到我手机上的？ 说实话，我用智能手机十几年了，每天收几十条推送，从来没认真想过这个问题。 直到我开始查资料。然后我发现了一件事。 你手机上的每一个 App，不管是微信、支付宝、抖音还是菜鸟裹裹，它们没有一个能直接把通知发到你手机上。 一个都没有。 你收到每一条推送，都经过了同一个中间人。在 iPhone 上它叫 APNs（Apple Push Notification service），在安卓上是 FCM（Firebase Cloud Messaging，谷歌家的）。 你没看错。你的微信消息、你的支付宝转账提醒、你的抖音私信，所有这些，都不是「微信服务器 → 你的手机」。而是「微信服务器 → 苹果/谷歌服务器 → 你的手机」。 所有 App 的通知，都在走苹果和谷歌的收费站。 这听起来很奇怪。为什么不能直接发？微信自己有服务器，我微信也登录了，为什么非要让苹果和谷歌夹在中间？ 答案是，电池。 你想象一下，如果你手机装了 100 个 App，每个 App 为了能随时收到通知，都必须各自在后台维持一条到自家服务器的长连接。100 个 App 就是 100 条连接，100 个后台进程，100 个在悄悄耗电的东西。 你的手机根本扛不住。别说一天一充，可能上午十点就没了。 所以苹果和谷歌想了个办法。他们不让每个 App 自己连服务器。他们让操作系统本身，在系统层面维持**一条**长连接，就一条，连接到苹果或谷歌的推送服务器。所有 App 的通知，全部走这条管道。 你的微信来消息了，微信服务器不是直接找你手机。它先把消息发给苹果的 APNs 服务器，APNs 再通过那条系统级的唯一连接，转发到你手机上。 所以你知道为什么 iPhone 的推送比安卓稳定那么多吗？ 因为 iPhone 上，每一个 App 的推送都走同一条 APNs 通道。安卓呢？谷歌的 FCM 在国内基本不可用，于是华为、小米、OPPO、vivo、魅族各自建了自己的推送通道。你用小米手机，App 的推送走小米通道。你用华为，走华为通道。如果你用的 App 没有接入某个厂商的通道，那这个 App 在你手机上就收不到后台推送。除非它自己偷偷在后台跑进程保活。 这就是为什么很多安卓用户抱怨「微信消息延迟」。不是微信的问题，是你手机厂商的推送通道和微信之间的配合出了问题。 好，回到我刚才说的那个场景。飞机落地，飞行模式一关，十几条消息同时弹出来。 这些消息是什么时候到的？ 答案是，在我关掉飞行模式**之前**，它们就已经到了苹果的 APNs 服务器上。微信服务器把消息发给了 APNs，APNs 发现我的手机关机/飞行模式，就先帮我把消息存着。等我手机一恢复连接，APNs 立刻把存着的消息一次性推过来。 苹果的 APNs 对每个 App 只保留**最新一条**离线消息。比如微信给我发了五条消息，APNs 只存最后一条。这也是为什么有时候你收到一条微信推送，点进去发现有五六条未读。推送只显示了最后一条，前面几条在 App 打开后才从微信服务器拉取。 谷歌的 FCM 大方一点，最多存 100 条，保存最长 4 周。 这就是你断网后还能收到消息的全部秘密。不是消息穿越了空气，是消息在苹果和谷歌的服务器上排队等你。 说到底，推送通知这件事，从它被设计出来的第一天起，就不是「App 发给用户」。它是「App 委托平台发给用户」。 平台给你提供了统一的推送管道，帮你省了电，让你的手机不用被 100 个 App 的后台进程拖死。代价是，所有通知都要从它手里过一遍。 苹果和谷歌不止知道你在用什么 App。它们知道你什么时候收到了什么消息，谁发给你的，发了多少次。它们可以选择延迟投递、降低优先级、甚至在你开了「通知摘要」之后帮你把不重要的消息打包到下午三点一起发。 你以为你在收通知。其实苹果和谷歌在替你决定，你什么时候看到什么。 你手机上的每一条推送，都不是 App 发给你的。是苹果和谷歌发给你的。App 只是把话递了过去。 这个系统从 2008 年 iPhone 引入 APNs 开始，到现在十七年了，没有变过。而且短期内也不会变。因为它确实是最好的方案。一条系统级连接，比一百条各自为政的 App 连接，对电池友好太多了。 只是大多数人从来没想过这件事。 下次你手机一亮屏，收到一条「你浏览过的商品降价了」的时候，可以想想这条消息的旅程。 拼多多的服务器写了一行字。这行字先飞到加州库比蒂诺的苹果服务器，或者加州山景城的谷歌服务器。在那里等了一会儿，然后穿过太平洋，降落到你手上。 你以为是拼多多在叫你。其实中间还有个库克。 --- 读到这你可能会想，行，我知道了。推送都得过苹果和谷歌的手。那如果我不想过他们的手呢？ 比如我一个写代码的，服务器上跑着几个脚本，爬虫跑完了我想让它告诉我一声，CI 构建挂了我想立刻知道，磁盘快满了别等我发现的时候已经爆了。这些场景，我怎么把消息从服务器推到我自己手机上？ 难道我要为了这个去注册一个 Apple Developer 账号，每年交 99 美元，然后自己写 APNs 对接逻辑？ 显然不现实。 这就要说到另一个世界了。和 App 运营推送不同，个人开发者、运维、脚本小子们早就有了一套自己的工具箱。它们的目标不是给几百万用户发营销通知，而是「用一个 HTTP 请求把消息送到自己手机」。 我举个例子你就明白了。 你写了一个爬虫，每天早上八点自动抓某个网站的最新文章。跑完了，你想在微信里收到一条提醒，「今日抓取完成，新增 12 篇」。怎么做？ 最简单的办法，用 Server 酱。你注册拿一个 SendKey，然后在爬虫脚本最后加一行 curl。 ```bash curl -X POST "https://sctapi.ftqq.com/<你的SendKey>.send" \ -d "title=爬虫完成" \ -d "desp=今日新增 12 篇文章" ``` 爬虫跑完，这行命令执行，你微信里就弹出一条消息。不需要自己写 App，不需要研究 APNs 怎么对接，不需要维护长连接。就一行 curl。 Server 酱在背后做的事情其实很简单。它接收你的 HTTP 请求，然后通过微信测试号、企业微信等通道把消息转发到你手机上。它更像一个「通知中转站」。你把话递给它，它帮你送到微信。 但这东西有个问题。它依赖 Server 酱的服务器。人家跑路了你怎么办？人家改收费规则了你怎么办？人家被微信封了接口你怎么办？ 所以有人做了开源自建版。 message-pusher 是一个比较完整的替代品。你自己部署一个服务，支持微信、企业微信、飞书、钉钉、Bark、Telegram、Discord 等一堆通道。有 Web 管理后台，可以管理多个用户。它还兼容 Server 酱的 API 格式，你之前写的 curl 基本不用改。 Heimdallr 更轻。它的定位是「通知网关」，不是你部署一个完整后台，而是一个轻量的路由器。你把 Bark、企业微信、ntfy、飞书等各种通道配置好，它帮你做转发。还支持 Serverless 部署，基本零成本跑起来。 如果你不想依赖微信呢？微信毕竟不是为这种场景设计的，接口随时可能收紧，消息模板也可能被限制。 那就用 ntfy。 ntfy 的思路特别简洁。你自建一个 ntfy 服务，手机装一个 ntfy 客户端。然后任何地方、任何脚本，发一个 HTTP PUT 或 POST 到你的 ntfy 服务器，手机立刻就弹出通知。 ```bash curl -d "备份完成，耗时 3 分钟" ntfy.mydomain.com/my-server ``` 就这么一行。消息到了你的 ntfy 服务，然后通过 WebSocket 推到你手机的 ntfy 客户端，客户端触发系统通知。整个过程不经过苹果的 APNs、不经过微信、不经过任何第三方。全程你自己的服务器和你自己的客户端在对话。 当然，ntfy 在 iOS 上受限于系统限制，后台推送还是走了 APNs。但它至少让你的消息不用过微信那关。 类似的还有 Gotify，更偏 Android 和 Web 端。 如果你在做产品，不是一个脚本通知的问题，而是整个产品的通知中心要搭建起来。用户要在 App 内收站内信、要收邮件通知、要收短信、要收 Push。Novu 这种基础设施就派上用场了。它提供统一的 API，把 Inbox、邮件、短信、Push 这些渠道编排起来，支持工作流、条件分支、摘要合并。但这已经是另一个级别的东西了，和我们说的「脚本发个通知到手机」不是一个赛道。 还有一个专门做 App 推送的工具叫 gorush。它是 Go 写的推送网关，直接对接 APNs、FCM、华为 HMS。如果你有自己的 App，已经有用户的 device token，gorush 帮你把消息发给系统推送服务。它解决的是「服务端怎么调用 APNs/FCM」，不是帮你做用户运营。 所以你看，整个推送世界的格局其实分两层。 上层是苹果和谷歌控制的系统级推送。所有 C 端 App 的通知，不管你是微信还是抖音还是拼多多，都得走这条路。这是为了电池、为了系统稳定性，你没办法绕过去。 下层是开发者和运维人员自己搞的「通知工具箱」。Server 酱、ntfy、Heimdallr、message-pusher、Gotify，这些工具的存在是因为苹果和谷歌的推送体系根本不是为「服务器告警」「脚本通知」「爬虫完成提醒」这种场景设计的。你要用官方的 APNs 给自己的脚本发通知，那得先写一个 iOS App、上架 App Store、拿到 device token，然后才能调用 APNs 接口。 杀鸡用牛刀都不够形容这件事的荒谬。 所以总结一下。如果你只是一个写代码的，想让服务器上的事情发生时你能第一时间知道， 想省事，用 Server 酱，一行 curl 搞定，消息到微信。 想自建、不想依赖第三方服务，用 ntfy 或 Gotify，自己部署，自己掌控。 想微信收到但不想用托管服务，用 wecomchan 或 Heimdallr，走企业微信通道。 要做产品通知中心，用 Novu。 要给自己 App 做推送，用 gorush。 下次你服务器磁盘快满了，与其等用户告诉你网站打不开，不如让脚本在磁盘用到 85% 的时候给你发一条 ntfy 通知。 比库克转告你快多了。