要在海王出海平台显示图标未读提醒，思路很简单：服务端统一维护未读计数并通过推送或接口告知客户端，客户端根据平台用角标 API 或推送 badge 显示，网页则用 Badging API 或降级修改 favicon/title；同时要处理权限、去重、同步和并发，保证计数一致性和低延迟。
先把总体思路讲清楚（为什么要这样做）
核心思想是把“未读数”作为一个可被信任的单一事实源（single source of truth），放在服务端；客户端只负责展示与同步。这样做有两个好处：一是多设备登录时能保持一致，二是能把复杂性集中到服务端处理（例如合并通知、节流、权限判断）。
用一句话解释给非技术的同事
服务端记着有几条没看，手机和网页靠“收到服务端告诉我的数”把角标显示出来；不用靠客户端猜到底还有几条。
分平台的具体实现路径（一步步做）
不同平台的实现细节不一样，我把常见场景拆成四类讲：iOS 原生、Android 原生、网页/PWA、以及常见跨平台框架（React Native、Flutter 等）。
1. 服务端设计（必做且优先）
- 维护一个未读计数字段：每个用户或每个消息流保留一个最新未读计数（例如 unread_count）。
- 提供查询与订阅接口：REST/GraphQL 接口用于主动查询，WebSocket / Server-Sent Events / Push 通道用于推送变更。
- 事件化与幂等：服务端发出“未读变更事件”时携带时间戳与版本号，便于客户端做幂等处理与并发合并。
- 权限与节流：不要每次消息都发一次角标推送，合并短时间内的变更以降低流量和系统负载。
2. iOS（原生 App）
iOS 的角标（应用图标上数字）只能由系统设置，通常通过 APNs 的 payload 中的 badge 字段或者 App 本地设置 UIApplication.shared.applicationIconBadgeNumber。
- 最佳实践：服务端在推送时同时发送 badge 字段为最新未读数。例如：{“badge”: 5}（APNs JSON）。
- 权限与用户设置：需要用户允许推送权限，且 iOS 会在用户设置里允许/禁止角标显示，开发者应在应用内引导用户开启。
- 静默推送更新角标：可以用 content-available 静默推送在后台更新计数，但 iOS 对静默推送有频率限制，不可靠，优先使用 badge 字段。
- 注意：如果用户在 App 内手动清空未读，App 应同时向服务端同步清零，避免下次推送再次出现旧数。
3. Android（原生 App）
Android 的角标支持非常依赖 Launcher（桌面启动器）和厂商。自 Android O（8.0）后，系统在 Notification Channel 层面支持角标显示，但各厂商行为不同。
- NotificationCompat.setNumber()可用于提示数量，但并非所有 Launcher 显示为角标。
- 厂商兼容：三星、华为、小米等有自己 API，第三方库 ShortcutBadger 可覆盖多部分机型但不是官方保证。
- 推荐做法：发送带数字的推送通知（FCM），并在 App 启动/后台同步服务端 unread_count；对支持的 Launcher，数字会反映为角标。
- 示例：FCM payload 可包含 “notification”: {“title”: “…”, “body”: “…”, “badge”: “5”}（注意不是所有设备/版本都识别 badge 字段）。
4. PWA 与 Web 页面
网页环境限制更多。现代 Chromium 内核浏览器支持 Badging API，可以直接在已安装的 PWA 上设置角标；未安装或不支持时需要降级策略。
- Badging API（Chrome 等）：在 Service Worker 或页面中调用 navigator.setAppBadge(count) 与 navigator.clearAppBadge()
- 降级方案：修改 favicon（动态生成带数字的 favicon）或修改 document.title 前缀（例如 “(3) 网站名”），这在桌面浏览器上最通用但体验差异大。
- Web Push：推送通知 payload 可以携带 badge 图标字段（用于通知 UI），但不会自动改变桌面图标角标，只有 Badging API 才能改变已安装 PWA 的角标。
5. React Native / Flutter 等跨平台框架
- React Native：常用库包括 react-native-push-notification、@react-native-firebase/messaging、react-native-notifications，配合 react-native-badge 或原生模块实现角标（iOS/Android 分别实现）。
- Flutter：flutter_local_notifications、flutter_app_badger 等插件，可以在各平台调用对应 API。
- 要点：跨平台框架最终还是调用原生机制，必须分别处理 iOS/Android 的差异。
数据一致性与同步策略（容易出问题的地方）
显示未读数看起来简单，真正难的是多端同步、并发更新与误差消除。下面列出常见问题和解决方案。
常见问题与对应策略
- 竞态条件：两个设备同时标为已读，服务端应使用乐观锁或原子聚合避免计数出错。
- 离线/恢复：客户端离线期间本地修改需记录变更序列号，重连后按序同步给服务端并以服务端返回为准。
- 重复推送：推送通道可能导致重复通知，客户端应根据事件 id 或版本号做幂等处理。
- 频率与节流：服务端对短周期内大量变更做合并（例如 10 秒内合并为一次推送）以减少电量和流量消耗。
具体示例：APNs / FCM / Badging API 的典型 payload
下面给出简化后的示例，实际实现时按平台 SDK 要求构造。
| 平台 | 示例 Payload / 调用 |
| APNs（iOS） | {“aps”:{“alert”:”你有新消息”,”badge”:5,”sound”:”default”}} |
| FCM（Android） | {“notification”:{“title”:”新消息”,”body”:”你有未读”,”badge”:”5″},”data”:{“unread_count”:”5″}} |
| PWA（Badging API） | 在 SW 或页面中调用 navigator.setAppBadge(5) 或 navigator.clearAppBadge() |
用户体验与细节（不只是技术）
角标是很敏感的 UX 元素，显示不准确会降低信任。下面几点会让体验更稳当：
- 优先展示“可操作”的未读数：例如把“未读评论”与“系统通知”分开，避免把不重要的事件也计入总数。
- 提供手动刷新入口：当用户觉得角标不对时，一个明显的“刷新”按钮比重新安装更友好。
- 在设置里说明角标来源与权限：让用户知道角标依赖系统通知权限和安装状态。
- 兼容性提示：在某些 Android 机型或桌面浏览器上角标不可用，应有备用提示（例如网页 title）。
测试与上线注意事项
上线前请覆盖这些测试场景
- 单设备正常推送角标、清零、后台静默推送更新
- 多设备同时登录，读/未读在不同设备间同步
- 推送权限被禁止时的降级展示（网页 title 或应用内角标）
- 网络抖动、离线后数据同步的幂等性
- 不同厂商 Android 的角标展示差异
监控与运维要点
角标功能上线后，建议监控以下指标：
- 推送送达率与失败率（APNs / FCM）
- 服务端未读计数的异常波动（突然大增/大减）
- 用户反馈中的“角标不准”事件数与典型机型
最后说几句经验性的建议
做角标这件事，技术上是若干平台差异的集合体，但真正考验的是设计和运维：如何把“唯一可信的未读数”放到服务端，如何优雅地降级到网页方案，如何处理并发和离线场景。不要指望一个方案一次性解决所有机型，先把服务端设计好，再在每个平台做最小可行实现，逐步覆盖特殊厂商。
如果你现在要上手实现，可以按这个顺序动手：一、把未读数接口和事件通知做好；二、在 iOS/Android 加入角标逻辑；三、为 PWA 做 Badging API 与 favicon 降级；四、做好监控与测试。沿途遇到具体平台的坑再具体攻克就好。