先明确两者的定位差异
Ad Hoc 和 TestFlight 都是苹果官方提供的测试分发方式，但设计目标并不相同。Ad Hoc 更像“把一台台设备登记进描述文件”的定向分发，测试范围由开发者自己维护的 UDID 列表决定；TestFlight 则是苹果托管的公开或半公开测试通道，测试者通过邀请或公开链接加入，由苹果负责分发与版本管理。理解这一点，后面的设备上限、有效期和安装体验差异就都能解释得通。
设备上限：一个按设备数，一个按人数
Ad Hoc 的核心限制在设备数量。每个开发者账号每年可登记的测试设备数量有限，且设备一旦绑定，在账号年度周期内通常不能随意替换，换机、刷机、重装都可能消耗或占用名额。团队如果测试机多、人员流动大，很容易出现“名额用完了但还没测完”的尴尬。
TestFlight 的限制维度是测试者人数，而不是物理设备数。同一个测试者换设备登录，一般不会像 Ad Hoc 那样额外占用一个设备位。对需要拉上运营、客服、外部合作方一起体验的团队来说，TestFlight 的名额管理压力明显更小。
- Ad Hoc：关注 UDID 列表，设备绑定后替换成本高。
- TestFlight：关注测试者账号，人员变动处理更灵活。
- 两者都需要提前规划，避免测试中期才发现名额不够。
如果你的团队已经在为 UDID 名额发愁，可以顺带看看站内关于设备绑定与名额规划的说明，思路是相通的：设备与名额管理相关服务。
有效期：短周期验证 vs 长周期灰度
Ad Hoc 构建本身没有“到期”概念，但描述文件和签名证书有有效期，证书过期或描述文件失效后，已安装的应用会无法启动，需要重新签名分发。这意味着 Ad Hoc 更适合短周期、可控范围内的验证，比如提审前的最后一轮回归。
TestFlight 的构建有明确的可用期限，苹果对每个构建的可测试时间有统一规则，到期后测试者需要更新到新构建。好处是版本迭代节奏被强制拉齐，坏处是老版本无法长期保留给测试者使用。对于需要长期挂着给外部人员体验的产品，这一点要提前和对方说清楚。
- 短周期、内部小范围验证：Ad Hoc 更直接。
- 跨部门、外部人员参与、需要持续灰度：TestFlight 更省心。
- 无论哪种方式，都要把证书和构建到期时间写进发布日历。
安装体验：一步安装与多步折腾
Ad Hoc 的安装体验取决于分发方式。测试者通常需要先提供 UDID，开发者把设备加进描述文件后重新打包，再通过网页、二维码或第三方平台下载安装。过程中常见的问题是描述文件未信任、设备未登记导致安装失败、企业证书被吊销等，对非技术测试者不够友好。
TestFlight 的体验更接近正式应用商店：测试者安装 TestFlight App，接受邀请或打开公开链接，点击安装即可，后续版本更新也有提醒。缺点是测试者需要额外安装一个 App，并且要接受苹果的测试条款；部分企业网络环境对 TestFlight 的访问也可能受限。
从运营角度看，Ad Hoc 适合“能沟通、能配合操作”的内部测试者，TestFlight 适合“不想教、只想让对方点一下”的外部体验者。两者并不是替代关系，很多团队会先用 TestFlight 做广泛体验，再用 Ad Hoc 做提审前的定向验证。
怎么选：按测试阶段而不是按习惯
一个实用的判断方法是看三个问题：测试者是否稳定、测试周期是否短、是否需要频繁换设备。三者都偏向“稳定、短、不换机”时，Ad Hoc 足够；只要有一项偏向“人多、周期长、设备杂”，TestFlight 的维护成本通常更低。把分发方式的选择写进测试计划，比事后补救更有效。
如果你还在处理签名安装失败、描述文件失效一类的问题，可以参考站内关于 iOS 签名安装排查的整理，先定位是证书、描述文件还是设备登记环节：iOS 签名与分发支持。