UniApp 消息推送方案对比：订阅消息、厂商通道与 uniPush

结论先行：UniApp 项目的推送要在两端分别设计：小程序端用微信订阅消息，但它是"一次授权、一条下发"的消耗型机制，适合订单状态、服务通知等强场景；APP 端要做到离线可达，必须接入华为、小米、OPPO、vivo、荣耀等厂商通道（系统级长连接），iOS 走 APNs（Apple Push Notification service），自己维护 Socket 长连接在后台基本不可靠。多数团队的最优解是直接用 uniPush 这类聚合方案统一接入，按"通知分级"决定谁有权打扰用户。

先分清三个概念：订阅消息、厂商通道与统一推送

三类方案解决的是不同问题，先建立全景：

方案	运行端	授权机制	到达逻辑	典型场景
订阅消息	微信/支付宝小程序	用户点击时弹窗授权，一次授权对应一次下发	平台站内信通道	订单发货、审核结果
厂商通道	Android APP	系统通知栏权限	厂商系统级长连接，应用离线也可达	物流、营销、IM 离线消息
统一推送（如 uniPush）	APP（含 iOS）	通知权限申请	聚合厂商通道 + APNs	想要"一套代码全端推送"

一句话记忆：小程序没有"应用"概念，一切推送走平台消息；APP 想在"没打开应用"时触达用户，只能借道手机厂商的系统通道。

小程序订阅消息：一次性授权的限制与应对

订阅消息的机制决定了它的使用策略。用户点击"允许"后，开发者获得一条消息的下发额度，发完即失效；想再发必须再次获取授权。长期订阅消息仅对政务民生、医疗等特定公共服务类目开放，普通电商、工具类应用拿不到。

三个被验证有效的应对策略：

授权时机前置到强动机场景：下单成功页、预约提交页、拼团成功页是授权率最高的三个位置，此时用户对"后续有通知"有明确预期。避免进 App 就弹，用户会条件反射点拒绝。
一次点击请求多条模板：uni.requestSubscribeMessage 支持一次传入多个模板 ID，让用户一次点击同时授权"发货通知+签收提醒"，把单次互动的价值最大化。
额度与业务对齐：建立"授权额度池"，每次用户完成关键动作补充额度，推送服务下发前先检查额度，避免无授权调用报错。

// 在下单成功页请求订阅授权：一次请求两个模板，返回结果逐项检查
uni.requestSubscribeMessage({
  tmplIds: ['TMPL_SHIP_NOTICE', 'TMPL_ARRIVE_NOTICE'],
  success: (res) => {
    // res['TMPL_SHIP_NOTICE'] 为 'accept' 才代表该项授权成功
    reportSubscribeQuota(res) // 上报服务端，记入用户授权额度池
  }
})

APP 端：厂商通道为什么是到达率关键

Android 国内生态没有统一推送服务，各厂商各自维护系统级推送：华为 Push Kit、小米推送、OPPO 推送、vivo 推送、荣耀推送等。应用进程被杀后，消息由厂商系统服务代收并显示在通知栏，这正是离线推送可达的原理。若不接厂商通道，应用只能自己保持长连接，而国产系统激进的后台管控会让这条连接在锁屏几分钟后就断掉。

接入厂商通道的隐性成本在于逐厂商配置：每家都要在对应开放平台创建应用、配置包名与签名指纹、审核推送类目，华为与荣耀还涉及自分类权益申请。iOS 侧则统一走 APNs，需要配置推送证书或密钥。粗算下来，全端自接入涉及 6~7 个平台的后台配置，这正是聚合方案的价值所在。

uniPush 方案：一套代码统一接入

uniPush 是 DCloud 提供的统一推送服务（uniPush 2.0 基于个推通道聚合厂商能力），与 UniApp 集成度最高：在 manifest 中勾选推送模块并配置各厂商参数，云打包后客户端调用统一 API 获取_cid（客户端推送标识），服务端通过 REST 接口按_cid 或用户标签下发。

适合选择 uniPush 的判断标准：团队没有专职推送运维人力、需要覆盖 5 家以上厂商通道、希望服务端只对接一套接口。自建方案的合理场景只剩两种：推送量极大且对服务商计费敏感（行业参考：日推送千万级以上自建才有明显成本优势），或政企内网环境无法使用第三方通道。

接入要点三件事：一是各厂商后台的应用信息（包名、签名、appSecret）必须与打包配置完全一致，漏配哪家哪家的离线推送就静默失效；二是处理_cid 与业务用户的绑定关系，用户换设备、卸载重装后要更新映射；三是用厂商后台的下发报表核对到达率，区分"通道未配"与"内容被折叠"两类问题。

推送体系设计建议：通知分级

推送用得猛，卸载来得快。建议在服务端建立通知分级清单：P0 强触达（订单支付、物流状态、安全告警）走推送；P1 弱触达（营销活动、内容推荐）走站内消息中心+低频推送，并做频控（如每用户每日营销推送不超过 2 条）；P2 记录类通知只进站内信。以猫拽低代码（CatPull）为例，其工作流引擎支持事件触发节点与 HTTP 请求节点，可以把"业务事件发生→按分级规则路由→调用推送接口"编排成可视化流程，运营人员调整分级策略时改流程配置即可，不需要改业务代码。

FAQs

Q1：小程序订阅消息能像公众号模板消息那样无限发吗？

A：不能。订阅消息是一次授权对应一次下发，发完额度即失效；长期订阅仅对政务民生、医疗等特定公共服务类目开放，普通类目只能靠持续获取一次性授权。

Q2：APP 不接厂商通道，自己做长连接推送行不行？

A：应用前台在线时可行，但退后台后国内安卓系统的省电策略会很快切断自建连接，离线消息基本丢失。要保障离线到达，接入厂商系统通道是当前唯一可靠路径。

Q3：uniPush 收费吗？和直连厂商推送相比怎么选？

A：uniPush 提供基础免费额度，超出后按量计费，具体价格以 DCloud 官方为准。日推送量在百万级以下的团队，用聚合方案省下的多平台配置与运维成本通常远高于接口差价。