uniCloud数据库监听不支持实时推送，因缺乏WebSocket或长连接机制，客户端db.collection().watch()不可用；所谓“实时”需依赖轮询或自建WebSocket中转，且受小程序平台限制。
uniCloud数据库监听不支持实时推送
uniCloud 的云数据库本身没有 WebSocket 或长连接机制，db.collection().watch() 在客户端（如 uni-app）中不可用，这是最常被误以为能用的点。所谓“实时订阅”，实际只能靠轮询或服务端主动推——而 uniCloud 目前不提供内置的 Server-Sent Events（SSE）或 WebSocket 服务。
用云函数 + 定时触发模拟“近实时”更新
适合对延迟要求不高（秒级到分钟级）、数据变更频率低的场景，比如订单状态、审批进度等。核心思路是：前端定期调用云函数查最新数据，云函数从数据库读取变化后返回。
-
uniCloud.callFunction中传入时间戳或版本号作为参数，避免全量拉取 - 云函数内使用
db.collection().where().orderBy().limit(1).get()查最后一条变更记录 - 前端用
setInterval控制轮询频率，注意加防抖和取消逻辑（如页面卸载时clearInterval） - 别在 onShow 里无条件启动轮询，否则多个页面同时激活会放大请求压力
用 uniCloud 云对象 + WebSocket（需自建中转）
uniCloud 本身不托管 WebSocket 服务，但你可以把云对象当作后端 API 网关，配合第三方 WebSocket 服务（如腾讯云 TKE 上部署的 ws-server）做中转。流程是：
- 用户首次进入页面时，uni-app 前端连接你自己的 WebSocket 服务，并传入
openid或uid - 业务数据变更时，云函数写库后，再通过 HTTP 请求通知你的 WebSocket 服务：“给 uid=xxx 推送新消息”
- WebSocket 服务查在线连接并广播，前端监听
message事件更新 UI - 关键点：
uniCloud只负责写库+发通知，不处理连接管理；WebSocket 服务必须自己运维或选用 PaaS（如 Pusher、Socket.IO Cloud）
微信/支付宝小程序平台限制进一步压缩选择空间
即使你实现了 WebSocket，小程序平台也不允许前端直接连公网 ws:// 地址（仅支持 wss://），且部分平台（如支付宝）对后台保活、长连接有严格策略。更现实的做法是：
- 优先用
uni.getPushMessage（仅限部分厂商通道，覆盖有限） - 对强实时需求，改用服务端下发模板消息（微信
subscribeMessage.send）或订阅消息（支付宝alipay.open.app.subscribe.msg.send），但这是“单向通知”，不是双向数据流 - 若真需响应式数据同步，建议放弃纯 uni-app + uniCloud 方案，改用 Taro + 自建 Node.js WebSocket 服务，或接入 Firebase Realtime Database（需合规评估）
