先厘清两者的本质区别
Ad Hoc 是苹果开发者体系里的分发方式之一：开发者把测试设备的 UDID 登记到开发者账号，用对应的描述文件（Provisioning Profile）签名打包，安装包只能装到名单内的设备上。TestFlight 则是苹果提供的托管式测试服务，开发者把构建上传到 App Store Connect，由苹果审核后分发给测试人员，测试人员通过 TestFlight App 安装。
一个是“自己管设备名单、自己发安装包”，一个是“把包交给苹果、由苹果管分发”。这个底层差异，直接决定了后面的设备上限、有效期和安装体验。
设备上限：名单制 vs 邀请制
Ad Hoc 的核心约束是设备名单。每个开发者账号每年可登记的测试设备数量有上限，且同一台设备在同一账号下只计一次。这意味着团队要维护一份 UDID 清单，新增测试机、换机、设备丢失都要在名单里做增删，名额管理本身就是一项运营工作。关于名额的绑定逻辑和换机规划，站内 UDID 签名与设备名额相关服务 有更细的说明，这里只强调一点：Ad Hoc 的“上限”是硬上限，超了就装不上，没有临时扩容的余地。
TestFlight 走的是邀请制：开发者生成邀请链接或公开链接，测试人员用 Apple ID 接受邀请即可。外部测试人员数量同样有上限，但不需要收集 UDID，也不需要为每台设备单独维护记录。对测试人群经常变动的项目，这一点省掉了很多沟通成本。
- Ad Hoc：设备必须提前登记，名单外设备无法安装。
- TestFlight：按 Apple ID 邀请，不依赖 UDID 名单。
- Ad Hoc：名额是账号级资源，需要长期规划。
- TestFlight：测试人员进出更灵活，适合灰度扩量。
有效期：描述文件与构建过期是两回事
Ad Hoc 安装包能不能继续用，取决于签名所用描述文件的状态。描述文件有有效期，证书被撤销或描述文件过期后，已安装的应用可能无法再启动。团队需要提前规划重签和替换包，否则测试中途会突然“打不开”。
TestFlight 的构建也有有效期，苹果对每个构建的可测试时间有明确限制，过期后测试人员需要安装新构建。两者的差别在于：Ad Hoc 的过期往往和证书、描述文件绑定，出问题时影响面是“所有装了旧包的设备”；TestFlight 的过期更接近“这个构建到期了，换下一个构建”，流程上更平滑，但要求团队保持稳定的上传节奏。
实操上，建议把两类有效期都写进发布日历：Ad Hoc 关注证书与描述文件的到期时间，TestFlight 关注构建上传与测试窗口的衔接。掉签、证书撤销后的用户侧表现和补包流程，可以参考站内 签名与分发服务 中的说明，提前约定好通知和替换的时间线。
用户安装体验：几步操作、几道门槛
Ad Hoc 的典型流程是：开发者提供 ipa 或安装页面链接，用户用 Safari 打开，确认安装，系统提示“未受信任的企业级开发者”或需要信任描述文件，然后才能启动。整个过程对非技术用户并不友好，常见问题是链接在微信内打不开、用户不知道去哪里信任证书、安装到一半失败。
TestFlight 的流程是：用户先安装 TestFlight App，接受邀请，然后在 TestFlight 里点安装。首次使用多了一步装 App，但之后的更新由 TestFlight 统一管理，用户不需要反复处理描述文件。对内部测试和外部灰度来说，这种体验更接近正式发版。
- Ad Hoc：分发链接 → Safari 安装 → 信任描述文件 → 启动，步骤多且易出错。
- TestFlight：装 TestFlight → 接受邀请 → 安装/更新，更新路径统一。
- Ad Hoc：每次换包都要重新分发链接，用户可能装到旧包。
- TestFlight：构建更新在 App 内提示，版本管理更清晰。
怎么选：按测试阶段和人群决定
如果测试人群固定、设备可控、需要快速拿到反馈，Ad Hoc 更直接，前提是设备名额规划到位。如果测试人群会扩量、需要外部用户参与、希望减少安装支持成本，TestFlight 更合适，但要接受构建审核和有效期节奏。
不少团队的做法是两者并用：核心内部测试机用 Ad Hoc 保证随时可装，外部灰度用 TestFlight 控制节奏。无论选哪种，都要把设备名单、证书有效期、构建过期时间当成发布流程的一部分来管理，而不是等到用户反馈“装不上”才回头排查。