要让“海王出海”平台图标显示未读提醒，先在手机系统里给应用开通知和角标权限；App要在推送或本地通知中带上角标数（iOS 用 APNs 的 badge 字段，Android 通过通知渠道或厂商角标接口）；服务器发送推送时同步计数并处理清零逻辑，这样客户端和服务端保持一致，才能稳定显示正确的未读角标。
为什么图标未读提醒会不显示？先把问题讲清楚
有人把图标角标当“魔法图标”，按下去它就会出现。其实不是，角标的出现是系统、应用和服务器三方一起完成的。想象一下：角标就像门口的信箱数字，要显示数字，门外（推送服务器）要塞信件，邮差（系统推送服务）要把信送到家，而房主（手机上的应用）要允许把数字贴在门上。任何一环出问题，数字就可能不正确或不出现。
三方协作的关键点
- 系统权限：手机必须允许应用显示通知和角标。
- 应用端：能接收推送、在收到时更新角标或展示本地通知带角标。
- 服务器端：推送payload要包含角标信息或提供可查询的未读数。
按平台逐步解决：iOS（最直接）
iOS 对角标支持比较统一，核心在 APNs 的 payload 里加 badge 字段，或者在应用内通过 UIApplication 的接口设置。但要注意用户权限和后台刷新。
步骤（开发者视角）
- 请求权限：在应用启动时向用户请求通知权限（UNUserNotificationCenter）。允许 badge。
- 发送推送时带 badge：APNs payload 示例：
{"aps":{"alert":"您有新消息","badge":5,"sound":"default"}} - 本地更新角标：应用运行时可用 UIApplication.shared.applicationIconBadgeNumber = n 来设置。
- 静默更新：若需要在后台更新角标，服务器可发送 content-available 的静默推送，应用在收到后设置 badge。但静默推送受系统限制（如省电模式、平台策略）。
- 清零策略：用户打开消息页时，应在合适的时机将 badge 清零或设置为正确数量。
常见问题与排查（iOS）
- 用户拒绝权限：引导用户到“设置 → 通知 → 海王出海”开启允许通知与角标。
- APNs payload 没带 badge：查服务器日志，确认发送的 JSON 包含 badge。
- 静默推送不触发：检查后台模式是否允许、是否被系统限制、是否滥用静默推送导致被降级。
- 角标错乱：确认服务端计数逻辑（增量 vs 绝对）是否一致；避免重复发送错误的 badge 值。
按平台逐步解决：Android（碎片化，需要针对厂商处理）
Android 的复杂在于厂商和系统版本差异。Android 8.0（API 26）以后引入了通知渠道，角标显示由系统或厂商桌面决定。部分厂商（如小米、华为、OPPO、vivo）提供各自的角标接口，需要兼容处理。
关键点一览
- 通知渠道（Notification Channel）：确保创建了合适的 channel，并在通知里使用对应 channel。
- 通知带数字：通过 Notification 的 setNumber 或类似字段携带数字，但并非所有桌面都会展示。
- 厂商角标 API：集成 ShortcutBadger、华为 Badge API、小米 Mi Push 提供的角标接口等。
- 通知管理权限：确保用户没有禁止应用通知或锁屏显示。
Android 常见实现思路
- 优先使用系统原生方式：对 Android 8+，在通知里通过 NotificationChannel 的重要性和通知内容触发桌面角标。
- 兼容厂商：对小米、华为、三星等主流厂商实现厂商专有接口；可用第三方库如 ShortcutBadger（注意兼容性并非全覆盖）。
- 本地与远程配合：当服务器发送推送时，payload 中传未读数；应用在收到后根据厂商接口设置角标。
示例表（不同厂商的处理建议）
| 厂商/系统 | 建议做法 |
| 原生 Android（Google） | 使用 NotificationChannel + Notification 的 number 字段，依赖桌面实现 |
| 华为（EMUI） | 使用华为提供的 BadgeManager 或 HMS 推送的角标字段 |
| 小米（MIUI） | 使用 miui 的通知角标接口或小米推送 SDK 的 badge 字段 |
| OPPO / vivo / realme | 调用厂商自有接口或使用第三方兼容库 |
| 三星 | 通常能通过系统通知渠道显示，也支持 Samsung 的 badge API |
服务器端设计：计数逻辑与推送策略
角标的正确显示很大程度上取决于服务器的计数策略。下面讲清楚如何稳健设计。
计数的两种思路
- 绝对计数（推荐）：服务器每次推送把最新的未读总数（例如 7）发送给客户端。优点是幂等，客户端收到后可直接展示，不会因为丢包或重复导致偏差。
- 增量计数（谨慎使用）：服务器只发送增量（例如 +1）。优点传输数据小，缺点容易和丢包或重复推送产生偏差。
清零和同步
- 用户打开消息页后，应用应通知服务器“已读”并请求服务器返回最新未读数，然后同步本地角标为服务器返回值。
- 若应用使用本地离线更新（比如用户离线阅读），应在恢复网络时与服务器进行一次全量同步，确保角标一致。
- 避免客户端盲目将角标清零，除非服务器也确认已读。
推送策略示例
- 实时推送：新消息到达，服务器发送包含最新未读数的推送（适合即时通讯）。
- 汇总推送：合并多条消息后，按一定频率推送最新未读数，减少推送频次。
- 容错机制：若长时间未收到推送，客户端可定期向服务器拉取未读数作为兜底。
用户端设置与引导：如何让用户自己检查和修复
很多时候问题在用户端设置，产品需要友好引导用户完成设置。
必要的用户引导步骤
- 首次打开应用提供简短说明，提示需要开启通知与角标权限，并给出去设置的快捷入口（使用 Intent 跳转到应用通知设置页面）。
- 在消息页显眼位置提示“角标未显示？点此查看设置”，说明可能因为省电策略或通知被禁用。
- 对常见厂商提供针对性的设置指南，例如 MIUI、EMUI、ColorOS 的角标权限位置。
引导示例文本（用于弹窗）
“为确保您能及时看到新消息，请在系统设置中为海王出海允许通知和图标角标（徽章）。设置后返回应用即可生效。”
调试清单：遇到问题按步排查
这里给出工程师和产品都能用的排查流程，确保问题能快速定位并修复。
通用排查步骤
- 确认用户是否安装了最新版本的 App。旧版本可能未实现厂商兼容逻辑。
- 检查手机设置：通知是否被禁用？角标权限是否关闭？省电或通知管理是否限制后台活动？
- 服务器日志：push payload 是否包含 badge 或未读数？是否收到推送回执？
- 客户端日志：是否接收到推送？收到后是否正确调用了设置角标的 API？是否有异常日志被抛出？
- 厂商差异：在同一型号手机上测试多个桌面（默认桌面、第三方桌面）以确认是否桌面不支持角标。
专门排查 iOS 的两点
- 使用 Apple 的反馈与推送日志确认 APNs 是否成功投递。
- 检查用户是否打开了“应用图标标记”与“允许通知”。
专门排查 Android 的几点
- 在不同厂商机型测试，验证厂商角标接口是否被正确调用。
- 确认是否因为通知渠道的优先级导致桌面不显示角标。
- 检查是否有第三方桌面（如 Nova）不支持角标或需要额外配置。
实用示例：从用户角度一步步做（无代码）
如果你是普通用户，遇到“图标没有未读数”该怎么办，我会这样一步步帮你排查：
- 第一步：打开手机设置 → 应用管理 → 海王出海 → 通知，确认“允许通知”和“图标角标”已打开。
- 第二步：返回系统设置，检查省电/后台管理，确保海王出海未被限制自启或后台活动。
- 第三步：在应用内手动刷新消息页，或登出再登录一次看是否同步角标。
- 第四步：重启手机测试，排除系统临时异常。
- 第五步：若仍异常，截取设备型号、系统版本、应用版本，将这些信息反馈给客服或技术支持。
让角标稳定显示的最佳实践（给产品与开发团队）
- 使用“绝对计数”策略，服务端作为单一可信来源发出未读总数。
- 在推送 payload 里统一包含未读字段，并在客户端收到时以服务器值为准。
- 实现本地兜底拉取：客户端定期/在特定场景向服务器拉取未读数，修正可能的偏差。
- 对主要 Android 厂商做适配并记录兼容矩阵，明确哪些机型需特殊处理。
- 优化用户引导，避免用户一开始就拒绝权限导致后续问题难追踪。
常见陷阱与应对策略
- 陷阱：只依赖客户端计数。应对：以服务器为准并保证幂等更新。
- 陷阱：静默推送被系统屏蔽。应对：结合用户可见推送或拉取机制作为补偿。
- 陷阱：第三方桌面不支持角标。应对：通过在应用内明显位置显示未读提示，不能完全依赖角标。
- 陷阱：权限“允许通知”但未允许“角标”。应对：在提示里明确区分并引导用户设置两项权限。
测试矩阵示例（供 QA 参考）
| 测试项 | 要求 |
| iOS 推送带 badge | APNs 收到并在锁屏/桌面显示正确数字 |
| Android 原生通知渠道 | 在 Android 8+ 设备通知显示并桌面角标同步 |
| 小米/华为/OPPO 兼容性 | 在对应机型上角标按服务器值显示并在打开应用后清零 |
| 权限变更后行为 | 用户关闭再开启权限，角标能正常恢复 |
小技巧与用户体验细节
- 避免“99+”之外的无意义大数，角标过大的数值会影响美观与可读性，建议限制显示上限并在消息页细化实际数量。
- 当用户在其他设备（PC、网页版）阅读消息时，服务器应同步更新所有设备的未读数，避免单端显示错误角标。
- 在消息数量变化很频繁的场景，考虑合并推送或使用“新的会话/重要消息”类的角标策略，避免频繁闪烁。
总结性提醒（就是一点实用的聊天式建议）
说到这里，关键就是不要把角标当“客户端的单兵作战”。理想的做法是：服务端负责真实计数，推送把数值下发，客户端负责展示并在用户操作后回写服务端。对 Android 做厂商适配，对 iOS 保证 APNs payload 正确，用户体验上给出清晰设置引导。这样多管齐下，出现问题的概率和恢复成本都会小很多。
嗯，就想到这些，写着写着还会有些细节需要和开发团队再对齐，遇到具体机型或推送平台的特殊情况，记录下来做兼容表格会很有帮助。
