先分清两个容易混的东西

讨论推送之前，要把两样东西分开：一个是签名用的证书，决定这个 App 能不能被安装和打开；另一个是推送用的鉴权文件，决定服务端有没有资格向苹果的推送服务发消息。两者完全独立，一个过期不影响另一个，但它们的表现很容易被混为一谈。

本文说的是后者。它常见的形态有两种：一种是以 p8 为后缀的密钥文件（基于令牌的鉴权方式，一份文件可以给多个 App 用，有效期较长）；一种是以 p12 为后缀的证书打包格式文件（和具体 App 绑定，一年一换）。

到期会发生什么

推送鉴权文件到期后，服务端再向 APNs（Apple Push Notification service，苹果推送通知服务）发请求会被直接拒绝。表现是：服务端日志里出现鉴权失败，用户侧表现为一条推送都收不到，但 App 本身能正常打开和使用，一切功能都正常。这个特征很关键——App 能用但收不到消息，先查推送鉴权，不要去查签名。

为什么签名分发更容易踩这个坑

因为有了一条额外的变化链路。推送依赖两样东西同时对得上：App 的推送权限配置，以及服务端用的鉴权文件。它们共同指向一个标识，也就是这个 App 的身份标识（Bundle ID，应用的唯一包名）。

• 重签过程中，如果这个标识被改动过，服务端原来的鉴权文件就和新包对不上了，即使没到期也发不出去。
• 测试阶段用开发环境的鉴权，正式分发换成企业证书签的包，两个环境用的鉴权文件不一样，换了之后服务端没同步更新，就出现”测试能收到、正式收不到”。
• 多个 App 共用一份鉴权文件时，其中一个 App 的配置调整可能牵连到其他 App，排查时很难第一时间想到。

轮换的标准动作

建议按这个顺序做，不要跳步：

• 提前列一张台账：每个 App 用的是哪种鉴权方式、什么时候到期、对哪个身份标识、由谁保管文件。这张表比任何工具都管用。
• 在到期前一个月生成新的鉴权文件。生成动作要在开发者后台完成，需要拥有相应权限的账号。
• 部署时采用双份并存策略：服务端同时加载新旧两份鉴权文件，运行一段时间确认新文件工作正常，再下线旧的。这样万一新文件有问题，还有回退余地。
• 轮换完成后做端到端验证：从服务端发一条测试消息，确认真机收到，而不是只看服务端返回成功。

和签名到期错开

一个实用的建议：把推送鉴权文件的到期时间和签名证书的到期时间错开，不要把两件事挤在同一个月处理。同时到期时一旦出问题，很难快速判断是哪一条链路断了，排查时间会被成倍拉长。

常见误判

• 以为”App 打不开”是推送问题——那是签名或证书的问题，和推送无关。
• 以为”重装就好了”——重装会拿到新的设备令牌，但如果鉴权文件本身过期，重装多少次都没用。
• 以为”换个推送服务商就行”——服务商只是帮你发消息，鉴权文件还是要你自己出，换服务商解决不了到期问题。

最后一句

推送这类问题有个特点：它不影响 App 打开，所以很容易被拖，等到用户抱怨消息收不到才被发现。把它当作例行维护，在台账里标好下次轮换时间，比任何应急方案都有效。

---

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