先给结论：签完的 App 能正常收到推送，这件事和「签名」本身不冲突。真正决定能不能收到的是另外两样——签名时有没有把推送相关的权限配置留下来，以及服务端用的是哪一套推送环境。

推送走的其实不是 App 自己的路

iOS 的推送链路是：你的服务器把消息交给 APNs（Apple Push Notification service，苹果推送通知服务），由苹果的服务器再下发到设备，最后交给 App。整条链路上，App 是怎么装进手机的——App Store（苹果官方应用商店）下载、TestFlight（苹果官方测试分发渠道）、企业签名、超级签名——都不参与推送的传输过程。

所以「签名 App 收不到推送」这句话本身是个误诊。签名影响的是 App 有没有资格向 APNs 注册、以及注册到了哪一个环境，不是推送这条路通不通。

最常出问题的四个地方

• 推送权限声明在重签时丢了。重签名会重写包里的签名信息。如果新证书对应的授权配置里没有带上 aps-environment（推送环境声明，写在签名里的一组权限开关）这一项，App 启动时就拿不到 device token（设备令牌，APNs 用来定位你这台设备的字符串），推送会全丢。这是最常见的一处。
• 推送环境对不上。APNs 分 sandbox（沙盒，开发测试环境）和 production（生产，正式环境）两套。用个人/公司开发者证书签出来的包，通常落在开发环境；用企业证书签的包，一般落在生产环境。服务端如果只配了生产地址，开发环境拿到的令牌就推不通，反过来也一样。
• Bundle ID（应用唯一标识）被改了。推送证书是跟 App ID 绑定的，Bundle ID 一变，服务端用的推送证书就和包对不上，APNs 会直接拒绝这条下发请求。
• 设备令牌没更新。UDID（设备唯一识别码）不会变，但每次卸载重装后 device token 会重新生成。服务端如果缓存了旧令牌又不刷新，后台会显示「发送成功」，用户却一条都收不到。

三种签名方式的差别

企业签名（用企业开发者证书签的包）一般不限制安装台数，走生产环境居多，接推送相对省事；超级签名（按 UDID 绑定设备的签名方式）用的是个人/公司开发者账号的证书，默认落在开发环境，如果服务端只对接了生产环境，就要提前说明；TestFlight（苹果官方测试分发渠道）是苹果自己的通道，推送配置跟正式上架一致，但受 90 天有效期限制。三种路线在推送这件事上都能跑通，差别只在环境参数。

四步自查顺序

第一步，App 首次启动时确认有没有拿到 device token，拿不到就是权限声明的问题；第二步，确认服务端存的是最新一条令牌；第三步，确认服务端连的是哪个环境的 APNs 地址和端口；第四步，核对推送证书绑定的 App ID 与包里的 Bundle ID 是否完全一致。四步里有任意一步对不上，推送就到不了。

小结

签名不会「阉割」推送能力，会出问题的是重签名过程中的权限丢失和环境错配。送签前把「这个包有没有推送、走哪个环境、Bundle ID 是否保持不变」三件事跟服务商讲清楚，比事后从头排查省事得多。

---

我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920　微信：A-mk5888）