先厘清两者的本质区别
Ad Hoc 和 TestFlight 常被放在一起讨论，但它们并不是同一层面的东西。Ad Hoc 是苹果签名体系里的一种分发类型：用 Ad Hoc 描述文件把应用和一组已登记的设备 UDID 绑定，安装包只能装进这批设备。TestFlight 则是苹果提供的测试分发服务，构建上传后由 TestFlight 下发邀请，测试者通过 TestFlight App 安装。前者依赖设备白名单，后者依赖苹果的测试通道。
理解这一点后，设备上限、有效期、安装体验的差异就都能解释了。
设备上限：固定名额 vs 按人管理
Ad Hoc 的核心约束是设备名额。每个开发者账号每年可登记的测试设备数量有上限，且登记后当年内通常不能随意删除替换，名额属于稀缺资源。团队一旦把名额用在了错误的 UDID 上，或者测试机频繁更换，就会出现“包还在、名额没了”的尴尬。
TestFlight 不按 UDID 绑定设备，而是按测试者账号管理。内部测试成员数量有限，外部测试可以通过公开链接邀请更多人参与，具体人数上限以 App Store Connect 当前展示为准。对需要快速扩大测试样本的团队来说，这一点差别很实际。
- Ad Hoc：名额按设备算，登记即占用，管理重点是 UDID 准确性。
- TestFlight：名额按测试者算，邀请和移除更灵活，管理重点是构建版本与测试组。
如果团队测试机多、换机频繁，Ad Hoc 的名额管理成本会明显上升；如果测试人群分散、需要外部用户参与，TestFlight 的邀请机制更省事。关于名额浪费的具体治理办法，可以参考站内关于测试机与无效 UDID 管理的说明。
有效期：描述文件周期 vs 构建可用期
Ad Hoc 安装包能否继续运行，取决于描述文件是否有效。描述文件有明确的有效期，到期后应用通常无法启动，需要重新签名并让用户覆盖安装。这意味着 Ad Hoc 分发天然带有“到期提醒”的运营动作。
TestFlight 的构建也有可用时间窗口，每个构建上传后可被测试的时长有限，过期后测试者无法再安装该构建，需要上传新版本。两者的差别在于：Ad Hoc 的到期是证书与描述文件层面的，影响的是已装应用能否继续打开；TestFlight 的过期是构建层面的，影响的是还能不能装到这个版本。
运营上要区分两种提醒：Ad Hoc 要提前准备替换包并通知用户覆盖安装；TestFlight 要在构建过期前上传新构建并通知测试者更新。把这两类时间口径混在一起，容易出现“以为发了新包，其实旧包已失效”的问题。
安装体验：手动信任 vs 应用内安装
Ad Hoc 的安装链路通常是：用户拿到 ipa 或安装页链接，通过 Safari 或管理工具安装，首次打开可能需要在系统设置里完成信任步骤。对不熟悉 iOS 的用户来说，这一步容易卡住，需要图文引导。安装页的稳定性也很关键，域名或证书异常会直接让用户装不上。
- Ad Hoc：分发安装包或安装页，用户确认安装，必要时完成信任，再打开应用。
- TestFlight：用户先安装 TestFlight App，接受邀请，再在应用内点击安装或更新。
TestFlight 的体验更接近 App Store，更新提醒、版本说明、崩溃反馈都由平台承载，用户不需要理解签名概念。代价是测试者必须先装一个额外应用，并且构建要经过苹果的测试审核流程。Ad Hoc 则更直接，但对用户的操作能力和分发页稳定性要求更高。
如果安装页经常打不开，问题往往不在签名本身，而在域名解析、证书或备用入口，站内 分发与签名服务 相关说明里有排查思路。
怎么选：按阶段和人群决定
一个实用的判断方式是看测试规模和阶段：
- 小范围、设备固定的内部验证，Ad Hoc 更直接，包体控制在自己手里。
- 需要外部用户参与、测试人群会变化，TestFlight 的邀请和更新机制更合适。
- 临近上架前的灰度，TestFlight 更接近真实商店体验；Ad Hoc 更适合功能验证和内部回归。
两者也可以并行：核心测试机用 Ad Hoc 保证随时可装，外部体验用户走 TestFlight。关键是把设备名额、描述文件有效期、构建可用期分别记录到同一张表里，明确谁负责提醒、谁负责替换包。分发方式只是工具，真正决定测试效率的是这些时间点和责任人的管理。