先明确两者的定位差异
Ad Hoc 和 TestFlight 都属于 iOS 应用在上架前的测试分发手段，但底层机制不同。Ad Hoc 依赖开发者账号里的设备登记：只有 UDID 被写入描述文件（Provisioning Profile）的设备，才能安装带该描述文件签名的安装包。TestFlight 则是苹果提供的托管式测试服务，测试者通过邀请加入，由 TestFlight App 完成下载与安装，不需要开发者手动收集 UDID。
这个底层差异，直接决定了设备上限、有效期和安装体验三条主线上的表现。
设备上限：登记制 vs 邀请制
Ad Hoc 的核心约束是设备数量。苹果对每个开发者账号每年可登记的测试设备数量有上限，且设备一旦加入，通常要等到账号年度续费周期才能清理。这意味着：
- 设备名额是稀缺资源，测试机、客户样机、外包同学的手机会互相挤占；
- 每次新增设备都要重新收集 UDID、更新描述文件、重新签名打包；
- 设备列表管理混乱时，容易出现“名额用完了但真正要测的人装不上”。
TestFlight 走的是邀请制，测试者通过公开链接或邮箱邀请加入，不占用 Ad Hoc 的设备登记名额。外部测试员数量同样有上限，但管理方式是“移除测试员”而不是“清理设备”，运营动作轻得多。对需要频繁更换测试人群的团队，这一点差别很大。
有效期：签名周期 vs 构建周期
Ad Hoc 安装包的有效性绑定在描述文件和签名证书上。描述文件过期、证书吊销或设备名单变更，都会让已安装的包无法继续使用，用户往往表现为“打开就闪退”。团队需要自己维护一套到期提醒和重签流程。
TestFlight 构建有独立的可用期限，过期后测试者无法再安装该构建，需要上传新构建。它的好处是把“过期”这件事交给了平台提示，测试者能看到剩余天数和更新提醒；代价是每次迭代都要走一遍上传与审核流程，外部测试的首个构建还需要经过 Beta 审核。关于不同阶段该用哪种分发方式，可以参考站内 iOS 测试分发方案说明 中的阶段划分。
安装体验：手动信任 vs 一键安装
这是对测试者影响最直接的一环。Ad Hoc 的典型流程是：开发者发安装包链接（通常是 itms-services 形式）→ 测试者用 Safari 打开 → 确认安装 → 回到桌面找到应用 → 首次打开时可能遇到“未受信任的开发者”提示，需要去“设置-通用-VPN与设备管理”里手动信任描述文件。步骤多、失败点多，非技术测试者经常卡在某一步。
TestFlight 的流程是：测试者先安装 TestFlight App → 接受邀请 → 在 App 内点击安装或更新。整个过程有版本说明、更新提醒和崩溃反馈入口，测试者不需要理解证书和描述文件。对于面向外部用户、客户或非技术同事的测试，安装成功率明显更高。
需要注意的是，TestFlight 要求测试者使用 Apple ID 登录，且部分场景下需要设备系统版本满足构建要求；Ad Hoc 则在网络和描述文件信任环节更容易出问题。两条路径的故障点不同，排查思路也不一样，可结合 安装失败排查清单 逐项核对。
怎么选：按测试对象和迭代节奏决定
- 内部小范围、设备固定：Ad Hoc 更直接，不需要测试者装额外 App，适合研发自测和固定客户样机。
- 外部测试、人群会变：优先 TestFlight，避免 UDID 收集和设备名额消耗。
- 高频迭代：TestFlight 的更新提醒能降低“测试者还在用旧包”的概率；Ad Hoc 每次改动都要重新分发链接。
- 合规与留痕：TestFlight 有测试者反馈和崩溃记录，便于收集问题；Ad Hoc 需要团队自建反馈渠道。
实务中不少团队会两者并用：核心设备用 Ad Hoc 保证随时可装，外部灰度用 TestFlight 扩大覆盖。关键是提前把设备名单、证书到期时间和构建版本号做成一张表，避免“包还能装但签不过”的尴尬。