uni-app 无法原生实现实时数据库推送，需通过 uniPush、WebSocket 或轮询模拟；uniCloud 云函数不支持数据库变更监听，必须显式触发通知；iOS 后台推送依赖 APNs 生产证书、权限授权及 CID 绑定。
uni-app 本身不自带数据库变更的实时推送能力，uniCloud 的云数据库（如阿里云 MongoDB、腾讯云 MongoDB、支付宝云 Firestore）也不原生支持监听集合/文档变更事件（即没有类似 Firebase 的 onSnapshot 或 MongoDB 的 Change Streams 直接暴露给前端）。所以所谓“实时更新推送”，必须靠主动触发 + 订阅机制 + 消息中转来模拟。这不是 Vue 响应式那种自动同步，而是「服务端发通知 → 客户端收通知 → 主动拉新数据」的闭环。
uniCloud 云函数无法直接监听数据库变更
你不能在云函数里写 db.collection('posts').watch() 并把变化推给前端——uniCloud 当前（2026年中）所有服务空间均未开放数据库变更流（Change Streams）的客户端或云函数侧监听 API。官方文档和控制台均无此接口，尝试调用会报 Method not found 或静默失败。
常见误操作是查到 MongoDB 有 watch()，就以为云数据库也能用。但 uniCloud 封装层已屏蔽该能力，且云函数运行环境也不支持长连接维持监听器。
- 云数据库增删改操作后，必须由业务逻辑「显式触发」推送（比如在云函数里调用
uniCloud.push.send()） - 前端无法被动等待“某条订单状态变了”，只能靠：WebSocket、uniPush、或轮询 + 云函数校验
- 如果你看到某些教程写了
db.watch，基本是混淆了自建 MongoDB 和 uniCloud 托管服务
可行路径只有三种：uniPush、WebSocket、云函数 + 客户端轮询
三者适用场景差异大，选错会导致 iOS 后台收不到、安卓被系统杀进程、或服务器压力暴增：
- uniPush：适合「非即时但需触达」的场景，如订单发货通知、活动开始提醒。它走厂商通道，APP 杀后台后仍能收到，但延迟通常 1–30 秒，且无法携带复杂数据（payload 限制 4KB，iOS 更严）
-
WebSocket：适合聊天、协作白板等强实时场景。需自建 ws 服务（Node.js + Socket.IO），并在云函数中通过 HTTP 请求或消息队列与之通信。uni-app 端用
uni.connectSocket连接，uni.onSocketMessage收数据。注意：iOS 后台最多维持 30 秒连接，必须配合 uniPush 做兜底 -
云函数 + 轻量轮询：适合低频更新（如每 30 秒查一次「我参与的活动状态」）。前端用
setTimeout或uni.startPullDownRefresh触发uniCloud.callFunction，云函数查库返回 diff 数据。别用setInterval死轮询，容易触发 uniCloud 频控（默认 100 次/分钟/客户端）
uniPush 实现「数据变更→用户通知」的关键三步
很多人卡在 CID 绑定和推送时机，导致消息发出去但设备收不到：
- 必须在用户登录后，立刻用
uni.getPushClientId获取push_clientid，并调用云函数将其与user_id存入uniCloud的opendb-push-user表（或自定义表）。不绑定，uniCloud.push.send就不知道推给谁 - 云函数内调用
uniCloud.push.send时，push_clientid必须是字符串数组，哪怕只推一人也要写成['xxx']；若传空数组或null，API 不报错但静默丢弃 - 消息内容字段名必须严格匹配模板配置。比如微信订阅模板字段叫
thing1，你传product_name就渲染为空。调试时先用控制台「测试推送」功能验证 payload 结构
示例云函数片段（发送订单状态更新）：
exports.main = async function (event, context) {
const { orderId, newStatus } = event;
const db = uniCloud.database();
const res = await db.collection('opendb-push-user')
.where({ user_id: event.userId })
.field('push_clientid')
.get();
if (res.result.data.length === 0) return;
<p>await uniCloud.push.send({
push_clientid: [res.result.data[0].push_clientid],
title: '订单状态更新',
content: <code>你的订单 ${orderId} 已 ${newStatus}</code>,
payload: JSON.stringify({ orderId, newStatus }) // 前端点击通知时可取用
});
};
最容易被忽略的坑：iOS 后台保活与权限链路
安卓上 uniPush 基本稳，但 iOS 上漏掉任一环都会导致「APP 在前台能收，切后台就收不到」：
- manifest.json 中 iOS 的
APNs证书必须是「生产环境」证书（开发证书仅限真机调试，且 Xcode 运行时才有效），且上传到 DCloud 开发中心后要等 5–10 分钟生效 - 用户首次启动 APP 时，
uni.getPushClientId返回的push_clientid是临时的；必须等uni.authorize({scope: 'scope.push'})成功后，再调一次获取，才是可用于推送的长期 CID - APP 切后台后，iOS 系统会终止 WebSocket 连接，也不会执行定时器。此时唯一可靠通道就是 uniPush —— 但前提是用户没在系统设置里关掉通知权限，且你的推送文案没触发苹果的「垃圾信息」过滤（比如含过多感叹号、链接、促销词）
真实项目里，建议在 onShow 生命周期检查 push_clientid 是否有效，无效则重新授权并上报新 CID 到云数据库，否则后续所有推送都失效。
