试过一圈推送方案后，我把通知都发给了 Bark

独立开发之后，通知变成了一件很具体的事：部署完成、定时脚本失败、监控告警、签到提醒。邮件太慢，微信太吵，我需要一个能稳定落到手机上的收件箱。

我用 iPhone，所以下面重点放在 iOS 上的到达率和可维护性。这一轮把 Bark 的链路完整跑了一遍，结论是：它适合作为 iOS 上的最终落点。下面把之前看过的方案收束一下，重点放在消息最后落在哪。

先按消息落在哪分类

类型	代表方案	适合场景	主要代价
聊天协作平台	钉钉、Telegram、飞书、企业微信、Discord、Slack	团队通知、群机器人、CI/CD 告警	要挂一个聊天 App；各有频率、权限或生态限制
聚合入口 + 手机推送	Server酱、Bark、PushDeer	个人接收程序通知、脚本告警	Server酱免费额度小；Bark 要保管 token；PushDeer 偏跨平台/自建
邮件	SMTP、Resend、SendGrid、各家邮件推送	日报/周报、低频摘要、归档	到达不及时；容易进垃圾箱；要配 SPF/DKIM
自建推送服务	ntfy、Gotify、message-pusher	高频、敏感、不想被限额	需要服务器和基础运维；iOS 支持各有短板

先想清楚这条消息是给团队看，还是只给自己看。团队消息适合留在聊天软件里；个人告警最好单独有一个落点，不然很容易被群消息淹没。

Bark：最省心的最终落点

Bark 是我现在默认的接收端，原因很实际：

免费，基本不限量，高频低频都能用
走苹果 APNs，秒级到达；App 不用一直开着，划掉也能收
开源，构建可验证，支持端到端加密
可以用官方公共服务器，也可以自建

代价只有一个：token 就是推送钥匙。token 泄露，别人就能向你推消息。把它放在环境变量或 CI Secrets 里，不要写进公开仓库；怀疑泄露就在 App 里重置 key。少数网络环境可以试备用域名 api1.day.app。

一个最小的调用长这样：

bash

export BARK_KEY="你的 key"

curl -X POST "https://api.day.app/push" \
  -H 'Content-Type: application/json' \
  -d "{
    \"device_key\": \"${BARK_KEY}\",
    \"title\": \"部署完成\",
    \"body\": \"yzqzy.dev 已上线\",
    \"group\": \"ci\"
  }"

敏感内容开端到端加密；想要更高稳定性或隐私，就自建 Bark 服务器，客户端里填自己的地址。

Server酱：统一入口，通道指向 Bark

Server酱 Turbo 更像一个统一入口：一个接口发消息，后台可以把通道切到微信、Bark、PushDeer 等。好处是将来换接收端不用改调用方代码。

免费版每天只有 5 条，所以它更适合低频通知。我的用法是：低频消息走 Server酱，通道选 Bark；超过 5 条/天的部分直接打 Bark，或者给 Server酱升额度。这样既保留了统一入口，也不会被免费额度卡住。

邮件：适合摘要，不适合告警

邮件是最容易被低估的一路。它不抢眼，但有三个好处：不用装 App、天然可搜索归档、几乎所有系统都能发。

缺点是时效和到达率。iOS 的邮件收取本来就不是实时的，垃圾箱和 SPF/DKIM 配置也会影响投递。所以我的用法是：邮件只做摘要，不做告警。日报、周报、长日志、需要留档的结果走邮件；盘中触发、部署失败这种要立刻知道的事，仍然走 Bark。

具体工具上，我现在用的是 Resend：hp-research 的授权申请站、Trade Signal 的授权邮件都走它。免费额度对个人项目够用，验证发信域之后投递率也稳定，比自建 SMTP 省事。

这里要分清两条线：hp-research 的告警链路目前只接了 Bark；邮件、企业微信和 Webhook 在告警文档里还标着 P2/P3，没有实现。授权邮件是另一套，走 Resend，不要和告警混在一起。

本地通道也别省

远程推送之外，我习惯在本地留一层：终端响铃、日志文件，以及 Herdr 的桌面通知。hp-research 的默认通知通道就是 terminal,log，配了 Bark key 之后才自动加上手机。

这一层的价值在于“人就在电脑前”的时候：终端和日志即时、可追溯，不会因为手机静音或网络问题错过。远程推送负责离开工位之后的那部分。

PushDeer：跨平台或自建倾向

PushDeer 支持 iOS、Android、Mac，适合未来可能混用设备的人。开源、可自建；但纯 iOS 场景下，消息管理和成熟度通常不如 Bark 直接。

聊天平台：看你在不在那个生态里

平台	适合	限制
飞书 Webhook	团队告警、国内触达	群机器人只能单向推送，个别安卓机后台可能延迟
企业微信机器人	消息落在微信生态，免费	每分钟最多 20 条，超了直接丢
Discord	开发者小圈子	需要挂着 App；Embed 消息可读性好
Slack	企业工作流整合	个人用途成本和必要性一般
钉钉 / Telegram	已有生态	作为备选没问题

团队协作通知走这些平台没问题，但个人关键告警最好仍然落到 Bark，避免被聊天消息淹没。

自建：高频、敏感、想掌控链路

ntfy：轻量 HTTP pub-sub，安卓体验好；iOS 需要额外转发，适合愿意折腾的人
Gotify：纯自建通知服务，简单省资源，偏 Android + 浏览器
message-pusher：单文件自建“统一推送网关”，一个接口对接钉钉、飞书、Bark、Telegram、Discord 等，适合做聚合层

自建不一定要买一台新 VPS。NAS、已有的 Docker 主机，或者 Sealos Cloud 这类 Kubernetes 平台都能跑。Trade Signal 的 PostgreSQL 和 feed 服务就放在 Sealos Cloud 上，当时用的是免费额度。不过对一个通知服务来说，VPS + Docker 通常更省心；除非你本来就在 Sealos 上，否则没必要为它单独上一次集群。

我的组合

实时：脚本、监控、部署、签到提醒，全部直接打 Bark
摘要：日报、周报、长日志走邮件，和实时告警分开
本地：终端 + 日志，必要时加 Herdr 桌面通知
统一入口：低频用 Server酱，通道指向 Bark；高频直接打 Bark
团队：协作通知走飞书、企业微信或 Discord；个人关键告警留在 Bark
高频/敏感：自建 ntfy 或 Gotify，或者用 message-pusher 做自建聚合网关

总的来说，Bark 很适合当 iOS 上的“个人消息收件箱”；邮件负责摘要和归档；Server酱可以当统一入口但通道指向 Bark；聊天平台按团队生态选；自建留给高频、敏感和喜欢掌控链路的场景。

这套跑通之后，大多数个人推送需求就不用再折腾了。