先分清：用户看到的不是同一种错误
企业证书被撤销（业内常说的“掉签”）之后，团队内部往往只收到一句“打不开了”，但用户实际遇到的现象取决于 App 处于哪个阶段。把现象分类，是后续通知和补签的前提。
- 还没装：点击安装链接后无法完成下载，或安装到一半中断，提示“无法安装此 App”。
- 已装但没启动过：图标还在，点开时闪退或直接回到桌面。
- 已装且能启动：部分功能异常，尤其是需要校验签名、调用钥匙串或走网络鉴权的模块先出问题。
- 已装且离线可用：短期可能“看起来正常”，一旦触发系统校验或联网就暴露。
这四类现象对应的用户情绪完全不同：第一类会反复重试安装，第二类会以为手机坏了，第四类最危险——用户以为没事，团队也容易误判影响面。因此排查时不要只问“能不能打开”，而要问清“装的时候、第一次打开、联网之后”分别是什么表现。
通知用户：先给结论，再给动作
掉签期间最忌讳的是含糊其辞。用户不需要知道证书吊销的技术细节，但需要知道三件事：现在能不能用、要不要卸载、去哪里拿新包。建议通知话术按固定结构写：
- 现象确认：一句话说明“当前版本因签名失效无法正常使用”，避免用户怀疑是账号或网络问题。
- 数据说明：明确本地数据是否保留、是否需要先备份。涉及登录态的，说明重新登录后数据能否恢复。
- 操作步骤：给出卸载旧包、清理描述文件、重新安装新包的顺序，并说明是否需要先删除旧的企业信任设置。
- 时间预期：给出补签预计完成时间，以及期间可用的替代入口（如网页版、内测通道）。
通知渠道上，站内弹窗、短信、社群公告要口径一致。如果 App 已经打不开，站内弹窗基本失效，真正有效的是短信、邮件和外部社群。这一点在制定响应流程时经常被忽略。
切换通道：补签不是只有一条路
补签的本质是换一个仍有效的签名载体，但不同通道的恢复速度和用户成本差别很大。团队可以按下面的顺序评估：
- 企业证书补签：恢复快，但需要重新分发安装包，用户要卸载重装。适合内部工具和可控用户群。
- TestFlight 或内测通道：审核和名额有约束，适合能接受邀请流程的用户。
- Ad Hoc / UDID 签名：设备数量受限，适合测试机和核心用户，不适合大规模铺开。
- 网页版或轻量替代入口：不解决安装问题，但能保住核心业务不中断，适合作为过渡。
选择通道时，除了恢复速度，还要看用户是否愿意卸载重装、是否有设备绑定关系、是否涉及付费名额。相关服务边界可以在 站内服务说明 中对照确认，避免临时决策和既有约定冲突。
避免重复踩坑：把补签做成流程
掉签往往不是一次性事件。如果每次都靠临时拉群、手动发包，团队会持续消耗在重复沟通上。更稳的做法是把补签固化成几个可检查的环节：
- 监控与发现：除了用户反馈，建立定期自检机制，尽早发现签名失效，而不是等社群炸锅。
- 分级响应：按影响用户量、是否影响付费、是否有替代入口决定响应级别，避免所有掉签都按最高优先级处理。
- 包与配置管理：新包版本号、描述文件、信任设置步骤统一归档，减少用户按错步骤导致的二次失败。
- 通知模板：提前写好卸载、重装、信任设置的图文说明，掉签时直接套用，缩短响应时间。
- 复盘记录：记录本次掉签的触发原因、影响范围、恢复耗时，作为下次通道选择的依据。
如果团队同时维护多个分发通道，建议把“当前有效通道”“备用通道”“用户需不需要卸载”做成一张状态表，掉签时按表执行，而不是临场讨论。更多分发与签名相关的排查思路，可以参考 服务与支持入口 中的说明。
小结
企业证书被撤销后，用户侧的现象是分阶段的，通知要按阶段给结论和动作，补签要提前准备多条通道，流程要能复用。把这三件事拆开处理，掉签带来的影响通常能从“全面停摆”压缩到“一次可控的重装”。