用 Composer装推送组件不能解决配置和环境适配问题。需严格匹配dry_run与证书类型、手动启用厂商通道、setConfig后重建实例、区分各driver的certificate含义、定期清理无效设备ID、优先使用alias绑定用户、避免无限制重试、补充离线消息兜底逻辑。
直接上结论：用 composer 装推送组件不是万能解药，装完不配、配错环境、忽略厂商通道限制，90% 的“推送失败”都卡在这三步。
为什么 composer require edujugon/push-notification 装完还是收不到通知？
这个包本身是通用封装，不自动处理平台差异。它只是帮你把请求发出去，但能不能被 iOS 或 Android 系统真正接收，取决于你填的参数是否匹配当前环境。
-
dry_run必须和证书类型严格一致：开发证书配true，生产证书必须设为false，否则 APNs 直接静默丢弃 - Android 侧如果只走 FCM，但手机没 Google 服务（如国内华为/小米），
send()返回成功，实际根本不会弹窗 - 包默认不启用厂商通道（华为 HMS、小米 MiPush），要手动在配置里加
hms_enabled、xiaomi_enabled并传入对应密钥
setConfig() 动态改配置时容易踩的坑
很多人想根据用户设备类型动态切推送通道，但 setConfig() 不会重置已初始化的连接实例。调用后必须重新 new 一个推送对象，否则旧配置仍生效。
- 错误写法：
$push->setConfig(['driver' => 'hms']); $push->send();—— 依然走默认 FCM - 正确写法：
$hmsPush = new PushNotification('hms'); $hmsPush->setConfig([...]); $hmsPush->send(); - 注意：不同 driver 对
certificate字段含义不同——FCM 用 JSON 服务账号文件路径，HMS 用agconnect-services.json，别混着传
批量推送时 addAllAudience() 和实际送达率的关系
极光、个推等平台的 addAllAudience() 看似方便，但底层是按 RegistrationID 批量查设备状态。如果用户卸载 App 后 ID 未及时失效，或厂商通道 token 过期，这批 ID 就变成“幽灵设备”，拉低整体成功率。
- 建议每 7 天调一次
/v3/devices/status（极光 API）清理无效 ID - 对高价值用户，优先用
addAlias()绑定业务 ID（如 user_id），比依赖设备 ID 更可控 - 不要在队列任务里无限制重试失败推送——APNs 对频繁失败 IP 会限流，反而拖慢后续正常消息
最常被跳过的环节是离线消息兜底：iOS 通知被拒、Android 厂商通道失败后，是否写了 fallback 到短信或站内信的逻辑？这点不补，再准的 composer 包也救不了到达率。
