Safew 手机版推送收不到

Safew手机推送收不到，常见原因包括：通知被关、后台刷新受限、省电或流量保护、网络或VPN干扰、设备未在服务器注册、厂商推送通道问题、服务端证书或密钥异常。先检查系统通知与后台权限、关闭省电与流量保护、重启并切换网络；若仍无推送，导出日志与设备信息提交客服，服务端需核对APNs/FCM配置及推送返回码。谢谢

先把推送的原理简单说清楚（别被术语吓到）

把推送想象成三部分配合完成的“邮件投递”：设备（收件人）、推送网关（邮局，iOS 是 APNs，Android 多为 FCM 或各厂商自有网关）、应用服务器（寄信人）。应用服务器把消息和目标设备的“收件地址”（device token）发给网关，网关再把消息送到设备。如果任一环节出问题，消息就收不到。

为什么要知道这个？

• 用户端问题（设备设置、网络、厂商限制）会让系统直接丢弃或屏蔽通知。
• 服务端问题（证书、token、返回码）会让网关拒收或回报错误。
• 混合因素（比如 token 失效 + 省电策略）很常见，需要逐项排查。

用户端快速排查清单（iOS 与 Android）

下面分条来做，按顺序走一遍，很多问题都能靠这一套方法解决。

通用步骤（都应该先做的）

• 重启手机（很多临时挂起的权限或网络问题靠重启能修复）。
• 切换网络：从 Wi‑Fi 切到蜂窝数据再试，或反过来。必要时断开 VPN 或代理再试。
• 确保应用是最新版本，若有问题可尝试退出账号或卸载重装。
• 查看是否在其他设备上能收到推送（排除服务端全局问题）。

iOS 专用检查点

• 设置 → 通知 → 找到 Safew → 打开“允许通知”、锁屏/横幅/徽章按需打开。
• 设置 → 通用 → 后台应用刷新 → 确保 Safew 开启。
• 低电量模式（Low Power Mode）会影响后台活动，检查是否开启并尝试关闭。
• Focus/勿扰模式会屏蔽通知，检查 Focus 设置与通知过滤。
• 若是静默推送（只有 content‑available），需要允许后台刷新与合适的 apns‑priority（开发者角度）。

Android 专用检查点

• 设置 → 应用 → Safew → 通知 → 确认通知总开关和各通知渠道都已开启（Android 8+ 强制渠道管理）。
• 设置 → 应用 → 电池 → 允许后台活动 / 取消自启限制；关闭电池优化或把 Safew 加入白名单。
• 流量保护或省流模式下禁止后台数据，检查数据使用权限与“节省流量”设置。
• 确认设备有 Google Play 服务（GMS）支持；某些国产机需要厂商推送（如小米/华为/OPPO）或额外适配。
• 若使用第三方 ROM 或深度定制系统，厂商策略可能更激进，需开启“自启动”或“允许常驻”。

厂商推送通道的坑（为什么同为安卓，有的手机能、有的手机不行）

简单说，Android 世界不是统一的邮局：有 Google 的 FCM，有华为、小米、OPPO 等厂商自己的推送服务。没有 Google Play 服务的手机（例如部分华为/荣耀新机）必须接入厂商推送。应用若只走 FCM，会在这些设备上出现不稳定或完全收不到的情况。

• 小米：需要开自启动、锁定后台、允许推送（Mi Push）；有时要在安全中心里手动放行。
• 华为：若无 GMS，建议接入华为 Push Kit 或确保 HMS Core 工作。
• 其他厂商：OPPO、vivo 等也有自己的推送 SDK 或设置页面。

网络、中间件与企业环境常见问题

很多“手机收不到”并不是手机的问题，而是网络或防火墙拦截了与推送网关的连接。

• 公共 Wi‑Fi 或企业网络常有 captive portal（需要登录的页面），推送会在未授权网络下失败。
• 某些防火墙或代理会阻止到 APNs/FCM 的连接。APNs 传统端口 5223，但现在 APNs 也走 443（HTTP/2）；FCM 主要走 443。
• VPN 或企业代理可能会改变网络路由或证书，导致网关连接不稳定。

服务端与开发者应该怎样排查（给运维/开发的清单）

开发者和运维需要拿到证据：网关返回的错误码、发送时的 payload、目标 token，以及发送时间点的日志。

APNs（iOS）常见问题点

• 证书/Key 环境错配：沙盒（sandbox）vs 生产（production）弄混会导致 token 无效或拒绝。
• 使用 HTTP/2 API 时，确保 team id、key id、bundle id 等信息正确，token‑based auth 的 key 没过期。
• 常见返回错误：BadDeviceToken、Unregistered、ExpiredProviderToken、MissingTopic 等，要根据返回码定位。
• apns‑priority：发送显示通知通常用 10（立即），背景静默可用 5，优先级与 delivery 有关。

FCM（Android）与厂商通道常见问题

• 确保使用正确的服务器密钥或新的 FCM 令牌（HTTP v1 API 使用 OAuth2），Legacy key vs v1 的混用会报错。
• 常见返回错误：InvalidRegistration、NotRegistered、MismatchSenderId、Unavailable（需重试）。
• 对于无 GMS 的设备，要额外接入各厂商 SDK 并做 token 映射与合并策略。

常用的手动检测方法（示例）

这儿给两个很常见的测试方法，能快速判断是服务端还是客户端问题。

1) FCM 简单 HTTP 测试：向单个 token 发消息，看返回 JSON 的错误字段。
2) APNs HTTP/2 测试：用 curl 或工具发一个小 payload，观察 HTTP 返回状态与 body。

如何把问题描述清楚给客服/开发（这样能更快定位）

当你准备发工单或联系技术支持，把下面信息按清单提供，会大幅缩短来回问答时间：

• 设备型号、操作系统版本、应用版本。
• 是否使用 VPN、所在网络类型（Wi‑Fi/蜂窝）及运营商。
• 是否在其他设备能收到推送；是否只对特定账号或所有账号无推送。
• 大致时间点（UTC 或本地时间）、一次失败的消息 ID（如果有）、服务端返回日志或错误码。
• 附加：截图、设备日志（如果能导出）、token（注意敏感信息处理）。

表格：iOS vs Android 快速对比排查点

如何收集有用日志（一步到位的做法）

收集信息要有结构，运维更容易复现和定位：

• 记录时间（UTC）、设备信息（型号、系统版本）、应用版本号。
• 抓取应用内的推送 token（device token / registration id），并把发送时的 payload 与服务端返回粘贴出来。
• 如能获取手机日志（adb logcat／iOS Console），截取发送时间前后 1 分钟的日志片段。
• 标注是否为静默通知或带展示内容（影响系统调度策略）。

临时替代方案（当真找不到原因时用）

• 应用中增加短轮询或手动刷新（比如每次打开 App 拉最新消息），作为临时兜底。
• 对关键通知增加短信或邮件双通道提醒（适用于重要安全或到账类通知）。
• 给用户页面上增加“推送检测与引导”页，自动检测常见权限并展示开启步骤。

我知道这些信息看起来有点多，但按顺序来，先把设备层面必开的那几项（通知、后台、网络）确认好，很多事情就能迎刃而解。遇到复杂情况也不要慌，把上面列好的信息收集齐，交给支持或开发，他们拿到准确的 token 与返回码能快定位问题。好了，我这儿先想到这些，后面还想起来什么再补几句就更完整了……