先搞清楚：名额到底绑在什么上
超级签名（以及基于 Ad Hoc 描述文件的签名方式）的核心机制是设备授权：签名服务会把待安装设备的 UDID 写入描述文件，只有被写入的设备才能完成安装和启动。因此所谓“签名名额”，本质上是一份可被授权的 UDID 白名单容量，而不是安装次数或下载次数。
这带来两个容易被忽略的结论：
- 同一台设备重复安装、卸载重装，通常不会重复占用名额，因为 UDID 没有变化；
- 换一台设备，即使使用者是同一个人，也会被视为一个新的 UDID，需要重新占用一个名额。
所以当后台提示名额用尽时，先别急着追加购买，第一步应该是核对已占用 UDID 列表里有多少是真正还在用的设备。
名额被“吃掉”的几种常见情况
在实际运营中，名额消耗往往比预期快，原因通常集中在以下几类：
- 测试机没有回收。外包测试、临时借用机、刷机后的备用机，装过一次就留在白名单里。
- UDID 采集不准确。用户手动复制 UDID 时漏字符、大小写混淆，或从非官方渠道获取到错误值，导致同一台设备被登记多次。
- 设备更换但未解绑。员工换机、用户退货换新，旧设备仍占着名额。
- 内部多人共用账号。不同项目组各自提交设备，缺少统一台账，重复登记难以发现。
建议把 UDID 当成一项资产来管理：记录设备型号、用途（测试/正式）、提交人、提交时间与状态。哪怕只是一张共享表格，也能显著降低无效占用。
名额规划：先算清楚需要多少台
规划名额时，建议按“角色”而不是按“人数”估算：
- 固定测试机：按机型与系统版本覆盖需求配置，数量相对稳定；
- 内部试用设备：按团队规模留出一定冗余，但要设定回收周期；
- 外部用户设备：这部分波动最大，需要明确是长期保留还是阶段性使用。
一个实用的做法是预留 10%～20% 的余量应对换机和临时需求，同时为每批设备设定有效期。到期未续用的设备及时从白名单移除，把名额释放出来。关于按设备计费时的成本控制思路，可以参考站内这篇超级签名名额管理与成本控制的说明，里面把测试机、重复安装和无效 UDID 的处理拆得比较细。
更换设备时的注意点
换机是最容易出问题的环节，几个细节值得提前确认：
- 先解绑再绑定。确认旧设备不再需要安装新版本后，再释放其名额，避免出现“旧的删了、新的没加上”的空档。
- 描述文件需要重新生成。设备列表变化后，原有描述文件不会自动包含新 UDID，必须重新签名并分发，旧包在新设备上无法直接使用。
- 注意证书有效期。换机往往伴随重新打包，如果证书临近到期，建议一并处理，避免短期内二次折腾。
- 保留旧设备的过渡期。如果旧机仍在灰度验证中，可以暂缓释放，等新机验证通过后再回收名额。
另外，设备授权属于签名链路中的一环，如果安装阶段还遇到其他报错，可以对照iOS 签名安装问题排查中的分层思路，先区分是策略、证书还是信任步骤的问题，再判断是否与名额有关。
名额真的不够了，怎么处理更划算
如果核对后确认没有无效占用，仍然不够用，可以考虑三条路径：
- 扩容名额。适合设备规模稳定、长期使用的场景，管理成本最低；
- 清理低价值设备。把长期未活跃的测试机移出白名单，通常能回收可观数量；
- 调整分发方式。对不需要长期驻留的设备，评估是否改用其他分发渠道，把超级签名名额留给真正需要稳定安装的核心设备。
无论选哪条路，核心都是让“设备—名额—用途”三者对得上。名额管理做得好，签名环节的很多临时故障其实可以提前避免。