PushSharp是C#后端向Android/iOS发送推送最稳、文档最全且持续维护的方案，原生支持APNs和FCM，不依赖特定框架，错误处理与重试逻辑已封装完善。
直接用 PushSharp 是目前 C# 后端向 Android/iOS 发送推送最稳、文档最全、维护仍在继续的选择。它不依赖特定框架（.NET Framework/.NET 6+ 都行），也不强制你用某家厂商通道，APNs 和 FCM 均原生支持，且错误处理和重试逻辑已封装好。
PushSharp 怎么配 FCM（Android）证书和密钥
FCM 不再接受旧版 Server Key，必须用 Firebase Console 生成的 google-services.json 对应的 **服务账号密钥（JSON 文件）**。别再去填“Server Key”字段——PushSharp 的 FcmServiceBroker 只认这个 JSON。
- 在 Firebase Console → 项目设置 → 服务账号 → 生成新私钥，保存为
firebase-adminsdk.json - 初始化时用
new FcmServiceBroker(new FcmConfiguration("your-server-key"))是错的；正确写法是：var fcmConfig = new FcmConfiguration("your-project-id", "your-sender-id", "path/to/firebase-adminsdk.json"); - 注意：sender-id 是 Firebase 项目设置里的「Cloud Messaging」页显示的数字 ID，不是包名或 AppID
- 如果发不出去，先检查 JSON 文件是否被正确读取（路径权限、是否设为“复制到输出目录”），再确认项目 ID 和 sender-id 是否抄错
PushSharp 怎么配 APNs（iOS）证书或密钥
iOS 推送必须走 APNs，PushSharp 支持两种认证方式：p12 证书（已逐步淘汰）和 JWT（推荐）。如果你还在用 .p12 文件，得确保它没密码、导出时勾选了“导出私钥”，且代码里传的是完整路径 + 密码空字符串；但更推荐直接切到 .p8 密钥。
-
.p8文件从 Apple Developer Portal → Keys 页面创建，记下Key ID和Team ID - 初始化 APNs broker 时用：
var apnsConfig = new ApnsConfiguration(ApnsConfiguration.ApnsServerEnvironment.Production, "your-bundle-id", "path/to/AuthKey_XXXXX.p8", "your-key-id", "your-team-id");
- Bundle ID 必须和 iOS App 的实际 Bundle ID 完全一致（区分开发/生产环境），否则 token 注册会失败或通知静默丢弃
- 别漏掉
ApnsConfiguration.ApnsServerEnvironment.Production或.Sandbox—— 混用会导致“InvalidToken”错误
PushSharp 发送时提示 InvalidRegistration 或 BadDeviceToken 怎么查
这类错误基本都指向设备端 token 不合法或平台不匹配，和后端代码关系不大，重点看 token 来源和使用方式。
-
InvalidRegistration：常见于把 Android 的 FCM token 当成 iOS token 发给了 APNs，或反过来。务必在数据库里为每个设备存一个platform字段（值为"android"/"ios"），发送前做判断 -
BadDeviceToken：iOS token 格式错误（比如多了空格、少了字符）、token 已过期（用户重装 App 或系统重置后会变）、或当前用的是 Sandbox token 却发到了 Production 环境 - 别硬编码 token 测试——用真实设备注册流程拿到 token 后再发；模拟器无法收 APNs，FCM 在部分模拟器上也受限
- 上线前一定要跑一遍 token 生命周期测试：卸载重装 App → 拿新 token → 发通知 → 验证能收到
真正麻烦的不是第一次发成功，而是 token 过期、用户关闭通知、厂商通道限流这些隐性问题。APNs 的 Feedback Service 和 FCM 的响应状态码（如 NotRegistered）必须定期轮询并清理无效 token，否则推送成功率会持续下滑。这一步容易被跳过，但线上服务扛不住。
