先搞清楚：名额到底绑在什么上
超级签名的计费单位是设备，而不是安装次数。服务商在签名时会把你的 App 与一批 UDID 绑定，生成对应的描述文件（provisioning profile），设备安装后系统会校验“这台设备的 UDID 是否在授权列表里”。在列表里就能装，不在就装不上。
所以“名额用完”通常指两件事之一：一是当前签名证书允许绑定的设备数已经达到上限；二是你购买的名额包已经被占满。两者表现类似，但处理方式不同，前者只能等证书周期结束或换证书，后者可以追加购买。
需要强调的是：名额被占用后，已经装好的设备一般不受影响，真正受影响的是“新设备无法再签名”。很多人一看到后台提示就以为要掉签，其实不必过度紧张。
名额是怎么被悄悄吃掉的
常见消耗来源有以下几类，建议逐条对照排查：
- 测试机反复刷机或还原：部分场景下设备标识会变化，旧记录仍占位，新记录又占一个。
- 同一用户换机：旧手机没解绑，新手机再签一次，等于双倍占用。
- 无效或伪造 UDID：从非官方渠道获取的 UDID 格式不对，签名失败但名额可能已被预占。
- 内部人员批量试装：运营、客服、渠道各自拿设备试，缺少登记流程。
- 重复提交：用户网络差，反复点击安装，后台生成多条绑定记录。
如果这些环节没有台账，名额会在你毫无感知的情况下见底。建议把设备登记、解绑、回收做成固定动作，而不是等用完再补救。
名额规划：按“活跃设备”而不是“总用户”估算
规划的核心是把总量拆成可管理的池子。可以参考下面的思路：
- 区分正式用户与测试设备：测试机单独走一条签名通道，避免和正式用户抢名额。
- 预留 15%～20% 缓冲：用于换机、售后补签和突发情况。
- 设定解绑周期：例如用户换机后 7 天内必须提交旧设备解绑申请。
- 记录每一次绑定：时间、UDID、用途、责任人，出问题时能追溯。
如果业务本身设备流动性高，纯按设备计费的模式成本会持续上升。这时可以评估其他分发方式是否更合适，具体可参考站内的分发服务说明：/index.php#services。
名额用完了，可以怎么做
按优先级从高到低：
- 清理无效占用：把测试机、离职员工设备、重复记录解绑，往往能立刻腾出空间。
- 追加名额包：如果服务商支持扩容，这是最快的方式，但要确认新名额是否与当前证书同一周期。
- 更换签名证书：新证书通常带新的设备额度，但已装用户需要重新安装，务必提前通知。
- 调整分发策略：把非核心用户引导到其他安装方式，减少对超级签名的依赖。
无论选哪种，都要先确认“当前已装设备是否会掉签”。多数情况下不会，但换证书会改变描述文件，需要重新签名安装。
更换设备时的注意点
换机是名额消耗最集中的场景，几个细节容易出错：
- 先解绑再签新机：顺序反了，旧设备会一直占位到周期结束。
- 确认 UDID 来源可靠：让用户通过可信方式获取，避免手工输入出错。
- 保留旧设备记录一段时间：售后可能需要核对，但核对完要及时释放。
- 通知话术要提前准备：告诉用户换机后需要重新安装，避免以为账号出问题。
如果团队同时在做多种分发方式，建议把设备授权、证书状态和用户通知纳入同一套流程管理，减少信息断层。相关服务能力可在此了解：/index.php#services。
小结
名额用完不是灾难，而是一个管理信号。把设备绑定逻辑讲清楚、把测试机与正式用户分开、把解绑流程固定下来，绝大多数“用完”都能提前避免。真正需要警惕的，是既没有台账、也没有解绑机制，等到用户装不上才发现问题。