uni-app无法使用极光推送原生SDK，因官方不支持且存在兼容性问题；推荐采用uniPush2.0，其深度整合主流厂商通道，需在App.vue的onLaunch中正确获取并上报CID，确保云函数调用sendMessage时参数准确。
uni-app 用不了极光推送的原生 SDK
uni-app 官方不提供极光推送（JPush）的内置支持，plus.push 是 DCloud 自研通道，和极光的 JPushInterface 无任何兼容性。强行集成极光 Android/iOS 原生 SDK 会导致：云打包失败、HBuilderX 报 ClassNotFoundException、iOS 上因签名/entitlements 冲突无法过审。
常见错误现象：
- 真机运行时控制台报
ReferenceError: JPushInterface is not defined - 云打包提示 “找不到 jpush-android-plugin” 或 “duplicate symbol _JPUSHRegister”
- 即使本地调试能跑，上线后离线消息 0 到达率（厂商通道被绕过）
为什么 uniPush2.0 是更现实的选择
极光在 uni-app 生态里没有官方插件维护，第三方 uni-jpush 插件大多停更于 HBuilderX 3.4.x，不支持 uniCloud 调用、不处理 CID 同步、不兼容 Android 14 权限变更。而 uniPush2.0 已深度整合华为、小米、OPPO、vivo、APNs 等通道，由 DCloud 统一兜底协议适配与证书管理。
关键差异点：
-
uniPush2.0的cid是服务端唯一寻址标识，自动绑定设备+厂商通道，无需手动调JPushInterface.init() - 离线推送走系统级通道（如
HMS Push），不是极光的长连接保活，省电且合规 - 云函数调用
uniCloud.getPushManager().sendMessage()即发即达，不用自己搭中转服务
App.vue 中获取 cid 必须在 onLaunch 里执行
这是最容易出错的环节：CID（Client ID）必须在应用冷启动第一时间获取并上报，否则后续所有推送都找不到设备。放在 mounted、onShow 或某个页面逻辑里，大概率拿到的是空值或旧值。
实操建议：
- 只在
App.vue的onLaunch生命周期中调用uni.getPushClientId() - 拿到
cid后立刻通过uniCloud.callFunction上传到你自己的用户表（例如user_push表，字段：uid,cid,platform） - 不要依赖
plus.push.getClientInfo()—— 这是旧版 API，uniPush2.0 下返回值不可靠
示例片段：
onLaunch() {
uni.getPushClientId({
success: (res) => {
const cid = res.cid;
uniCloud.callFunction({
name: 'saveCid',
data: { cid, uid: uni.getStorageSync('uid') }
});
}
});
}
云函数调用 sendMessage 时 cid 错误直接导致静默失败
uniPush2.0 不会抛异常，sendMessage 返回 { code: 0 } 仅代表“请求已接收”，不代表“设备已收到”。如果传入的 cid 格式错误、过期、或根本没在 uniPush 后台注册过，消息就卡在 DCloud 推送网关，没有任何日志提示。
排查要点：
- 确认
cid是 32 位小写 hex 字符串（如"a1b2c3d4e5f678901234567890abcdef"），不是设备 IMEI 或 token - 检查云函数中
appId是否与 manifest.json 里配置的uni-app id（__UNI__xxxxxxx）完全一致 - Android 真机测试前，务必使用「自定义调试基座」或「云打包 APK」，普通 HBuilderX 基座的
cid属于 DCloud 官方应用，你的服务端无法推送
真正卡住人的地方从来不是“怎么写代码”，而是 cid 没对上、基座没换、包名签名和 uniPush 后台配置不一致——这三处任意一个出问题，推送就彻底静音，连错误都不报。
