uni-app 不能直接集成极光原生 SDK，因与 plus.push 体系不兼容，会导致云打包失败、真机报错、App Store 被拒及离线推送到达率为 0；唯一推荐方案是 uniPush2.0，它深度整合厂商通道，合规高效。
别直接集成极光原生 SDK —— 云打包会失败，真机跑不起来，上线后离线消息基本收不到。
为什么 uni-app 不能直接用 JPush Android/iOS 原生 SDK
uni-app 的 App 端构建依赖 DCloud 的 plus.push 体系，和极光的 JPushInterface 完全不兼容。强行把 jpush-android-plugin 或 JG-JPush 插件塞进项目，常见后果包括：
- 云打包报错：
ClassNotFoundException: cn.jpush.android.api.JPushInterface或duplicate symbol _JPUSHRegister - 真机调试时控制台抛
ReferenceError: JPushInterface is not defined - iOS 提交 App Store 被拒：因 entitlements 冲突或未正确配置
aps-environment - 即使本地能弹通知，离线场景（App 杀后台）下到达率为 0 —— 厂商通道没走通，纯靠极光长连接，安卓系统一杀就断
uniPush2.0 是唯一靠谱的接入路径
DCloud 官方深度整合了华为、小米、OPPO、vivo 和 APNs，uniPush2.0 不是“套壳极光”，而是用厂商系统级通道发通知，合规、省电、到达率高。它不需要你调 JPush.init()，也不需要自己管理证书或签名指纹。
-
cid（Client ID）由 uni-app 运行时自动生成，是服务端寻址设备的唯一标识 - 离线推送走 HMS Push、MiPush 等原生通道，不是极光保活连接
- 云函数里只需一行：
uniCloud.getPushManager().sendMessage()，不用搭中转服务 - 第三方插件如
uni-jpush已停更，不支持 Android 14 权限变更，也不处理cid同步逻辑
App.vue 中 onLaunch 是唯一正确的 cid 上报时机
很多人把获取 cid 的代码写在 mounted、onShow 甚至某个页面里，结果 cid 拿到的是空值或旧值，导致所有推送都找不到设备。
- 必须放在
App.vue的onLaunch生命周期内执行 - 上报动作要加防抖和重试（网络可能未就绪）：
uni.getProvider确认push可用后，再调uni.getPushClientId - 拿到
cid后，建议立刻通过云函数存入用户表，绑定当前登录账号，避免多设备覆盖 - 不要缓存
cid到本地存储再异步上报 —— 冷启动阶段没网时，这个值就丢了
如果你坚持要用极光原生能力（仅限本地打包）
仅当项目已用 Android Studio / Xcode 本地打包，且团队有原生开发人力维护时才考虑。云打包 + 极光 SDK 组合在 2026 年已事实不可行。
- Android：需手动引入
JG-JCore和JG-JPush本地插件，修改nativePlugins配置，并在manifest.json源码视图中补全permissions和features - iOS：Xcode 工程必须开启
Push Notificationscapability，profile文件里要有aps-environment字段，否则打包直接失败 - 每次 HBuilderX 升级都可能破坏插件 ABI 兼容性，比如
plus.push和JPushInterface的回调生命周期冲突 - Android 14 要求显式声明
FOREGROUND_SERVICE_SPECIAL_USE权限，极光 SDK 旧版未适配
真正容易被忽略的点是：cid 不是“获取一次就永久有效”。设备恢复出厂设置、用户清除应用数据、甚至某些厂商 ROM 的后台策略，都会导致 cid 变更。所以服务端必须支持 cid 失效后的自动 fallback 和重新绑定逻辑，不能只靠前端单次上报。
