服务端日志写着 code=80000000, msg=Success，推送请求被 Push Kit 服务端接受了，但用户手机上什么都没弹。这个组合最容易把人带到“再调一次接口”的方向上去，实际上云侧返回成功只代表请求被服务端收下了。端侧展不展示是另一条链路上的事，和云侧的成功码没有因果关系。

推送从服务端到用户眼睛，中间至少要过五道门：应用有没有通知权限、用户有没有关掉对应通道、消息类型有没有匹配权益、Token 是不是有效的、点击后的跳转配置对不对。任何一道门关上，表现都是“服务端说发了，端侧没反应”。

通知权限是第一道防线

requestEnableNotification 返回错误码 1600004 就是用户拒绝了通知授权。这种情况下不管推什么消息、用什么类型，系统都不会在通知栏展示。应用需要在合适的 UI 场景引导用户去设置里打开，而不是反复调用推送接口。

普通应用可以用 notificationManager.isNotificationEnabled() 做一次前置检查，关闭状态下把推送开关的 UI 如实反映出来，而不是显示“已开启”然后让用户等一条永远不来的通知。

消息分类权益决定了能不能打扰用户

没有申请通知消息自分类权益的应用，推送的通知默认落在资讯营销类。营销类消息有发送频次和场景限制，很多“推送不展示”的根因其实是消息被归到了营销类，然后触发了系统对营销消息的管控。

需要发即时提醒、日程、订单状态这类消息，就要申请对应的自分类权益，在消息体里带上正确的 category 和 push-type。权益没申请，消息不是“推送失败”，是“被归了类然后按类的规则处理了”。

Token与点击跳转的隐性关联

80300007 表示所有 Token 都无效。除了 Token 本身可能已过期（卸载重装、恢复出厂、主动删除都会导致 Token 变化），还有一个常见原因是没有发送对应 push-type 场景的权益。错误信息里的 noPushTypeRight 直接指明了这一点。

消息在通知栏出现了，点了一下没反应或者跳错了页面，问题通常在 module.json5 的 skills 配置。一个 skill 里配置多个 action 可能导致匹配失败，需要跳转的能力应该拆成不同的 skill 对象分别声明。通知的 want 参数和目标页面的 skills 匹配不上，点击事件会被系统吞掉。

json5

"skills": [
  {
    "actions": ["action.system.home"],
    "entities": ["entity.system.home"]
  }
]

后台静默消息的接收与唤醒

如果推送的是后台静默消息（Data Message），这类消息不会在通知栏展示，主要用于唤醒应用做数据同步。排查这类问题不能看通知栏，要看应用是否被拉起、onBackground 里的日志有没有打出来。静默消息受系统后台管控策略影响极大，设备处于低电量模式或休眠状态时，极大概率会被延迟投递。

开发警示与排查链路

遇到“云侧成功、端侧没反应”，按链路的顺序走：先确认通知权限开着，再看消息分类权益是否覆盖了当前类型，然后验证 Token 是否新鲜且有效，最后检查点击跳转的 skills 匹配。每一步都有明确的信号——权限有错误码，权益问题会体现在 80300007 里，Token 可以和服务端记录比对，skills 可以在本地用 want 模拟验证。不要一上来就重发消息，重发解决不了权限问题，也改变不了消息分类。