项目使用 uni-app + UniPush 2.0，目标平台为 HarmonyOS NEXT。
【问题现象】
- APP 进入后台后，可以正常收到系统顶部横幅通知。
- uniPush.sendMessage 返回 errCode=0。
- 推送响应明细为 successed_offline。
- 桌面应用图标角标不会在后台立即更新。
- 点击进入 APP，再返回桌面后，客户端调用 uni.setAppBadgeNumber 才能更新角标。
【已经确认】
- 后端传入的 body.badge_num 和 payload.badge_num 正确。
- 云函数 sendParams.badge 正确。
- 云函数使用的 Harmony 参数结构为：
options: {
harmony: {
HW: {
"/payload/notification/badge/setNum": 7
}
}
}
- 没有使用来源不明的 options.HARMONY.badge。
- setBadgeByCid 仅作为补充调用，不依赖它处理 Harmony 角标。
- 系统设置中已允许该 APP 显示桌面角标。
- APP 启动后调用客户端角标 API 可以正常显示角标。
【固定值测试】
后端本次实际未读数为 2。
为了排除后端未读数计算问题，云函数临时将以下参数全部固定为 7：
- sendParams.badge = "7"
- payload.badge_num = "7"
- payload.badge = "7"
- options.harmony.HW["/payload/notification/badge/setNum"] = 7
推送结果：
- 顶部横幅通知正常收到；
- UniPush 返回 successed_offline；
- APP 保持后台时，桌面角标仍然没有变化；
- 点击进入 APP 后再返回桌面，角标显示为真实未读数 2，而不是远程推送的 7。
这说明进入 APP 后显示的 2 是客户端重新请求未读数并调用 uni.setAppBadgeNumber 设置的，不是厂商推送设置的角标。
【脱敏后的发送参数】
{
"push_clientid": ["CID_已脱敏"],
"payload": {
"sessionKey": "PRIVATE:",
"sessionType": "PRIVATE",
"targetId": "",
"sessionName": "测试会话",
"unreadCount": 2,
"badge_num": "7",
"messageType": 0,
"badge": "7"
},
"request_id": "REQUEST_ID_已脱敏",
"force_notification": true,
"options": {
"harmony": {
"HW": {
"/payload/notification/badge/setNum": 7
}
}
},
"category": {
"harmony": "IM",
"huawei": "IM",
"vivo": "IM",
"XM": "IM"
},
"badge": "7",
"title": "测试会话",
"content": "2条未读：测试推送角标问题"
}
【脱敏后的响应】
{
"data": {
"RASS0702***": {
"CID_已脱敏": "successed_offline"
}
},
"errCode": 0,
"errMsg": "success"
}
【希望协助确认】
- options.harmony.HW["/payload/notification/badge/setNum"] 是否会被 UniPush 完整透传到 Harmony Push Kit？
- HarmonyOS NEXT 厂商通知是否支持在 APP 后台或进程挂起时直接设置桌面角标？
- successed_offline 是否能确定本次消息实际经过 Harmony 厂商通道？
- 当前现象是否可能属于 UniPush 鸿蒙通道的参数转换问题？
- 是否还需要在 DCloud 开发者中心、个推后台、华为开发者后台或云打包配置中额外开通角标能力？
- 是否有办法查看最终发送给 Harmony Push Kit 的原始请求体，以确认 notification.badge.setNum 是否存在？
如需完整 CID、appId 或请求标识，可以通过非公开工单或私信提供。
补充实机测试结果：
测试环境保持不变，推送响应均为 successed_offline，APP 在后台时均能正常收到顶部横幅通知。
- 使用绝对值设置角标：
options: {
harmony: {
HW: {
"/payload/notification/badge/setNum": 7
}
}
}
同时传入顶层 badge="7"。
结果：
- 顶部横幅正常收到；
- 桌面角标在后台没有变化；
- 进入 APP 后，客户端调用 uni.setAppBadgeNumber 才能显示服务端真实未读数。
- 使用增量方式设置角标：
options: {
harmony: {
HW: {
"/payload/notification/badge/addNum": 1
}
}
}
同时传入顶层 badge="+1"。
结果：
- 顶部横幅正常收到；
- APP 保持后台时，桌面角标可以立即自动加 1；
- 推送响应同样为 successed_offline。
当前实机结论：
- addNum 在 HarmonyOS NEXT 厂商离线通道中可以生效；
- setNum 在相同设备、相同应用和相同推送通道中不生效；
- 两次测试的主要差异只有 notification.badge 使用 addNum 或 setNum。
请协助确认：
- HarmonyOS NEXT 的 UniPush 厂商通道当前是否只支持 addNum，不支持 setNum？
- setNum 不生效是 Harmony Push Kit 的限制，还是 UniPush 参数转换问题？
- 是否存在让 setNum 绝对值生效的额外配置、版本要求或权限要求？
- 如果生产环境只能使用 addNum，官方是否建议在 APP 启动或回前台后通过客户端 API 校正绝对角标？
