TestFlight 是什么？从第一次邀请到成功安装的新手完整教程

核实日期：2026 年 9 月 17 日。本文以 iPhone、iPad 为主线。Apple 的界面和规则会更新，请以文中链接的官方说明及你实际看到的页面为准。

你做出了一个应用，想让朋友先试试，却还没准备好正式上架 App Store。直接发源代码不行，发一个安装包，对方也不一定能装。

这就是 TestFlight 要解决的问题。

大家说的“TF”，通常就是 TestFlight 的简称。它是 Apple 提供的测试分发服务：开发者上传测试版，邀请别人安装，收集反馈，再把改进后的版本发出去。测试者安装的是真正运行在设备上的应用，不是截图或网页演示。[1][2]

先记住三句话：

• 内部测试面向有相应 App Store Connect 权限的成员。
• 外部测试适合朋友、客户和社区用户，不需要给他们开发者后台权限。
• 每个构建最多测试 90 天，从上传当天开始计算。测试审核通过，不等于正式上架。[1][3]

如果你只是收到了别人发来的链接，可以先看第 9 节“测试者如何安装”；如果你要把自己的应用发给别人，就从头开始。

1. TestFlight、App Store Connect 和 App Store，分别是什么？

可以把一款新应用想成一家还在试营业的店：TestFlight 帮你请人来体验，App Store 则是正式开门营业的渠道。试营业也有期限和规则，并不是绕过审核的后门。

三个名字很像，做的事情却不同：

表格较宽时可左右滑动；键盘用户可聚焦后使用方向键。

你在 App Store 下载的是 TestFlight 这个工具，再通过它安装别人邀请你测试的应用。某个应用出现在 TestFlight 里，不表示它已经能在 App Store 搜到。[1][3]

Apple 用它把“发版本—邀请测试—收集问题—更新版本”串起来。现在的 TestFlight 不要求开发者逐个收集测试者的设备标识，也不需要为每位测试者单独制作安装描述文件。[2]

但它不会替你写好应用，不会证明所有功能都正确，也不会把测试版自动变成正式版。即使经过测试审核，也不能据此保证应用没有漏洞或不会丢数据。测试陌生应用时，不要拿唯一一份重要资料冒险。

2. TestFlight 的历史：它并不是 Apple 从零做出来的

理解历史，可以解释为什么旧教程里的名称、人数和操作方式会不同。

• 2011 年 1 月：第三方服务公开推出。当时测试未发布的 iPhone 应用，经常要处理设备标识、安装包和描述文件，再通过电脑上的 iTunes 同步。TestFlight 让无线安装方便了很多。这里说的是从私测走向公开服务的节点，不是公司的注册成立日期。[H1]
• 2012 年 3 月：被 Burstly 收购的消息公布。TestFlight 当时仍是第三方产品。[H2]
• 2014 年 2 月：Apple 收购 Burstly。TestFlight 随母公司进入 Apple。[H3]
• 2014 年 10 月：Apple 宣布通过 iTunes Connect 开放邮件邀请测试。iTunes Connect 是今天 App Store Connect 的前身，当时可邀请最多 1,000 人。注意，这是历史数字。[H4]
• 2017 年 7 月：可邀请的外部测试人数扩大到 10,000。[H5]
• 2018 年 9 月：Apple 推出公开邀请链接。开发者不用先逐个收集邮箱，也能通过分享链接招募测试者。[H6]

今天它已经覆盖 Apple 的多个平台，包括 iPhone、iPad、Mac、Apple Watch、Apple TV 和 Apple Vision Pro。本文用 iPhone 举例，不代表它只能测试 iPhone 应用，也不代表它能分发 Android 应用。[2][3]

3. 先认识五个词：测试版、版本、构建、分组和审核

测试版（Beta）：还在验证和改进的应用版本，可能存在问题。

版本（Version）：例如 1.0、1.1，用于标识一轮对外版本。

构建（Build）：某一次具体打包出来的应用。例如 1.0（12），意思是版本 1.0、构建号 12。修好一个问题后，可以上传 1.0（13）：对外版本相同，但安装内容已经不同。[7]

分组（Group）：决定哪些人能收到哪些构建。你可以建“团队”和“早期体验”两个组，给他们相同或不同的构建。一个组可以有多个构建，同一个普通构建也可以分配给多个组。[2][5][6]

测试审核（TestFlight App Review）：面向外部测试的 Apple 审核，与正式 App Store 发行的审核不是一回事。[1][6]

记住这个关系就不容易迷路：应用是整个项目，构建是其中某一份具体安装内容，分组决定谁可以试用。公开邀请链接属于外部组，不是永远固定在某一个构建上。

4. 开始之前，发布者和测试者分别要准备什么？

发布者要准备的东西

1. 有效的 Apple Developer Program 会员资格。Apple 当前标准价格为每年 99 美元，地区价格可能不同，部分符合条件的机构可以申请费用减免。TestFlight 包含在相关会员服务里，不是另买一个测试者订阅。[4]
2. 正确的 App Store Connect 应用记录。应用的标识、签名和上传内容必须对应，不能把另一个应用的安装包随意加进来。[7]
3. 足够但不过度的账号权限。上传构建可由账户持有人、管理员、应用管理或开发者角色操作；外部测试管理要求账户持有人、管理员或应用管理角色。能上传，不代表能操作所有外部测试设置。[6][7]
4. 测试资料。包括应用说明、反馈邮箱、希望大家测试的内容；外部审核还需要联系信息，以及审核人员能实际使用的登录或功能访问方式。[6][8]
5. 可以测试的设备和时间。上传成功不等于安装和主要功能都已经验证。

不要把自己的 Apple 密码发给朋友。让别人测试应用，应该发邀请，而不是共享管理账号。

普通测试者要准备的东西

你只需要 Apple 账户、兼容设备、TestFlight 和一份有效邀请。不需要付费加入开发者计划，也不需要进入开发者后台。[1][3]

截至本文核实日，Apple 测试者帮助页列出的 iPhone、iPad 要求是 iOS 16、iPadOS 16 或更高。但具体应用可以要求更新的系统，公开邀请也可以筛选设备和系统版本。能安装 TestFlight，不代表能安装里面的每个应用。[3][6]

如果使用工作或学校提供的受管理 Apple 账户，要特别检查资格：Apple 的外部测试帮助明确说明，这类账户不能用于测试构建；内部测试帮助另明确列出，在保留域名中创建的受管理账户不能用于测试。遇到这类情况，应核对对应帮助页及组织政策，不要把它当成邀请链接故障。[5][6]

5. 内部测试和外部测试，到底有什么区别？

最重要的区别是后台身份和权限，不是你和对方熟不熟，也不是邀请有没有通过邮件发送。

表格较宽时可左右滑动；键盘用户可聚焦后使用方向键。

内部测试者的合格角色包括：账户持有人（Account Holder）、管理员（Admin）、应用管理（App Manager）、开发者（Developer）、营销（Marketing），同时要能访问这个应用。[2][5]

私下通过邮箱邀请一个朋友，通常仍然应该选外部测试。外部不等于公开；你完全可以只邀请几个人，不启用公开链接。

不要为了少一道审核，就给普通测试者管理员权限。那不是一个安装开关，而是真实的后台管理权限。

另一个容易遗漏的限制：个人开发者账号最多可以增加 50 位 App Store Connect 用户。所以 TestFlight 的“100 位内部测试者”上限，并不表示每个个人账号都能额外创建 100 个后台成员。[9]

6. 如何添加 Build？先分清“上传”和“加入测试组”

这其实是两件事：

• 上传构建：把已经打包好的应用从开发或构建工具交给 Apple。
• 为组添加构建：在已上传的可用构建中，挑一份发给这个组。

App Store Connect 测试组里的“添加构建（Add Builds）”，不是把源代码拖进去就自动生成应用，也不是上传本地文件的按钮。[5][6][7]

第一次发布，后台还没有这个应用怎么办？

由账户持有人、管理员或应用管理角色进入 应用（Apps）→“+”→ 新建应用（New App），选择平台，填写应用名称、主要语言、应用标识（Bundle ID）、用于后台管理的 SKU 等所需信息，再设置成员访问范围并创建。应用标识必须与项目一致；如果还不知道该用哪个标识，先与负责打包的人确认，不要随意选择另一个应用的标识。

如果无法创建，检查账户持有人是否接受了最新协议。建好应用记录只是在后台建立管理入口，不是已经上传或上架。[15]

用 Xcode 上传的基本路径

如果你已经有一个 iOS 项目，可以按这个顺序操作：

1. 检查应用标识和签名团队是否与 App Store Connect 的应用记录对应。
2. 为这次新上传设置未重复的构建号，例如从 1.0（12） 增加到 1.0（13）。
3. 选择用于实际设备分发的目标，点击 Product → Archive 创建归档，而不是把模拟器版本拿去上传。
4. 在 Window → Organizer → Archives 中选中归档，点击 Distribute App。面向常规 TestFlight 和后续正式发行，选择 TestFlight & App Store；自定义流程中对应 App Store Connect 分发。按界面完成签名与上传。[16]
5. 上传后，到 App Store Connect → 应用（Apps）→ 你的应用 → TestFlight 查看。
6. 等待 Apple 处理。遇到出口合规问题，应根据应用实际使用的加密情况如实填写，不能为了继续操作一律选“不使用加密”。
7. 处理完成且构建可用后，再把它加入内部或外部测试组。

Xcode Cloud、Transporter 等工具也可以参与上传。工具不同，不代表可以跳过 Apple 的处理、合规、分组和外部审核环节。[7] 具体上传工具和 SDK 的最低要求会调整，操作时查看 Apple 当前上传要求。构建所用的 SDK 版本，不等于应用允许安装的最低系统版本。[18]

小心“仅限内部测试”这个选项

TestFlight Internal Only 是上传方式带来的限制：这类构建只能进入内部组，不能用于外部测试，也不能用于向正式用户发行。如果之后需要外测或正式发行，要用合适的方式上传一个新构建，不能只把原构建换一个组。[5][6]

但反过来，一个普通构建先加入内部组，不会因此自动变成“仅限内部测试”构建。不要把“现在给内部成员试用”和“这份上传被限制只能内部使用”混为一谈。

如果你在 AirBuild 里开发应用

你可以让 AirBuild 协助准备可分发构建、签名、上传，以及配置测试组和邀请。先说清楚“发到 TestFlight”，以及是给团队成员，还是外部朋友；再连接或确认有权限的 Apple 开发者团队，确认测试说明、反馈邮箱、审核联系人和是否开放公开链接。

Apple 的处理、外部审核、人数和有效期规则仍然适用。交付时应分清具体版本与构建号、哪个组已经可用、外部审核是否还在等待。AirBuild 协助完成流程，不等于可以绕过 Apple 审核，也不意味着模拟器验证已经覆盖所有真实设备行为。

以上是 AirBuild 的工作方式说明，不是 Apple 强制要求使用某个工具；没有 Mac 上的本地 Xcode，也不表示必须学习所有打包细节才能与他人协作发布。

7. 如何添加内部测试人员？注意这里有两次邀请

适用对象：你自己，以及确实需要访问应用后台的协作成员。

第一次：让对方成为有权限的后台用户

由账户持有人（Account Holder）、管理员（Admin）或应用管理（App Manager）角色添加用户：

1. 进入 用户与访问（Users and Access）→ 人员（People）。
2. 点击“+”，填写姓名和邮箱。
3. 分配合适的角色；角色允许限制应用范围时，只给需要的应用权限。不要默认授予管理员。管理员、财务，以及获得报告或证书等额外资源访问权的用户不能按单个应用限制访问，选权限前要看清范围。[9]
4. 发送邀请，让对方接受并激活后台访问资格。

Apple 当前说明，这种后台用户邀请三天后会过期，过期可以重发。它不是后面那份 TestFlight 邀请，更不是构建的 90 天期限。[9]

如果对方本来就有合格角色和该应用权限，可以跳过这一步。

第二次：把人和构建加入内部测试组

1. 进入 应用 → 你的应用 → TestFlight。
2. 点击 内部测试（Internal Testing）旁的“+”，新建一个组，例如“团队”。
3. 打开组，选择 邀请测试者（Invite Testers），或测试者列表旁的“+”。
4. 勾选符合条件的后台成员，添加到组。
5. 点击 添加构建（Add Builds），选择已处理完成、可测试的构建。
6. 填写 测试重点（What to Test）并添加。
7. 让对方在设备上安装 TestFlight，接受测试邀请，再安装应用。[5]

完成的标志不只是“名单里有人”。还要有可用构建，对方也要实际接受邀请并安装。

找不到要邀请的人？先检查他是否接受了后台邀请、角色是否符合、是否有这个应用的访问权限，不要马上重复上传应用。

部分内部组可以开启自动分发，但不要假定所有来源的构建都会自动加入所有组。Apple 当前帮助特别说明，Xcode Cloud 创建的构建需要在 App Store Connect 中手动加入组。[5]

8. 如何添加外部测试人员？

适用对象：朋友、客户、早期用户、社区测试者。这通常是第一次把应用分享给别人时更合适的方式。

先准备一个能接收构建的外部组

由账户持有人、管理员或应用管理角色操作：

1. 如果没有内部组，先建一个。Apple 当前外部测试教程把“先创建内部组”列为前提；这不表示必须先正式上架，也不表示外部测试者要先成为内部成员。[6]
2. 进入 应用 → 你的应用 → TestFlight。
3. 在 测试信息（Test Information）里填写测试版描述、反馈邮箱，并补齐审核所需的联系资料。需要登录时，提供有效的审核访问方式和操作说明，确保相关服务器可用。不要拿真实用户私人数据充当演示资料。[6][8][14]
4. 点击 外部测试（External Testing）旁的“+”，新建组，例如“早期体验”。
5. 进入组，点击 添加构建，选择平台、版本和具体构建。
6. 填写 测试重点，例如“创建一条记录，退出再打开，检查记录是否仍在”，而不是只写“随便试试”。
7. 按需要勾选 自动通知测试者（Automatically notify testers）。
8. 根据页面状态，选择提交审核或开始测试，等待任何必要的审核完成。
9. 通过邮箱、公开链接，或者两种方式一起邀请测试者。[6]

第一次通过，以后是不是都不用审核？

不是。

首次提交外部测试的构建需要完整审核；同一版本的后续构建可能不需要完整审核，但不能承诺以后永远免审。Apple 也要求重大测试版更新在分发前提交测试审核。[6][14]

审核耗时不固定。不要对别人保证“上传后几分钟一定能装”或“24 小时一定通过”。

如果添加构建时没有勾选自动通知，批准后还要执行 通知测试者（Notify Testers）：在 TestFlight 左侧的 构建（Builds）下选择平台和版本，再点该构建状态栏里的通知入口。已批准、已分发和对方已安装，是三件事。[6]

方式一：通过邮箱邀请

打开外部组，在 测试者（Testers）旁点击“+”。你可以输入新测试者的邮箱、选择已有测试者，或者导入名单。[6]

对方收到的是测试邀请，不会因此获得 App Store Connect 的管理权限。

方式二：创建并分享公开链接

打开外部组的测试者页面，选择 创建公开链接（Create Public Link）：

1. 选择 向所有人开放（Open to Anyone），或 按条件筛选（Filter by Criteria）。
2. 按需要设置链接招募人数上限，可设为 1–10,000，但仍受这个应用总外部测试人数上限约束。
3. 如果筛选，设置目标设备和系统版本条件。
4. 确认后复制实际生成的链接，发给朋友、放进社群、邮件或网站。[6]

链接通常以 https://testflight.apple.com/join/… 开头。要复制 Apple 生成的真实链接，不要自己编后面的代码，也不要把 App Store Connect 管理页面地址当作安装链接。

二维码也可以承载同一个链接，但它不是另一种分发方式，更不会绕过审核。

分享链接前，检查四件事

• 目标外部组里有你想分享的那个构建。
• 必要审核已通过，且已经开始分发。
• 构建没有过期，并兼容目标设备。
• 链接已启用，有剩余名额，筛选条件没有把目标用户挡住。[3][6]

链接能打开，不等于新版本一定能安装。旧构建还可用，也不代表最新构建已经分发给这个组。

公开链接可以被继续转发，不是保密名单。如果只想邀请确定的几个人，优先用邮箱邀请，并在应用自己的账户权限中做好访问控制。

通过公开链接加入的人，姓名和邮箱默认不会显示在 TestFlight 测试名单里，但安装日期、使用会话和崩溃等信息仍可见。对方主动提交反馈时也可能提供邮箱。这不代表对 Apple 或应用自身的登录系统完全匿名。[3][6]

以后更新构建，通常可以沿用同一个外部组的链接，不必每次重新招募所有人。你也可以在 管理（Manage）里修改筛选条件、人数限制或停用链接。停用链接是停止新的加入入口，不等于删除已有安装、注销应用账户或清空服务器数据。[6]

9. 测试者如何安装、更新、反馈和退出？

拿到邀请后，在用于测试的 iPhone 或 iPad 上操作：

1. 从 App Store 安装 Apple 官方 TestFlight。
2. 打开邀请邮件或公开链接。
3. 根据页面提示进入 TestFlight，选择 接受（Accept），再点 安装（Install）。
4. 阅读测试重点，然后开始使用。
5. 有新构建时，在 TestFlight 更新，也可以开启自动更新。老测试者可能直接看到 更新（Update）或 打开（Open）。[3]

普通外部测试不需要开发者的密码，不需要后台角色，也不需要你先创建一个专门的沙箱账户。

手机上已经有正式版，会安装成两份吗？

通常不会。同一应用的 TestFlight 测试版会替换设备上的 App Store 版本。[3]

所以先备份或导出重要数据。测试版可能改变数据格式，旧版本不一定能读回新版本写入的数据，不要把切换版本理解成保证无损的操作。

如果开发者仍提供其他有效构建，你可以通过 以前的构建（Previous Builds）选择。它不是永久保存所有历史版本的下载仓库。[3]

怎样反馈，开发者最容易看懂？

打开 TestFlight 中的应用，点 发送测试反馈（Send Beta Feedback）。支持的系统也可以在测试应用里截图后发送反馈；崩溃后可能出现分享补充信息的提示。[3]

比“不能用”更有帮助的写法是：

我使用［设备型号］、［系统版本］，应用是［版本与构建号］。打开设置后切换语言，再返回首页，预期文字会一起切换，实际首页还是旧语言。重复试了两次都能遇到，附截图。

不要把密码、付款信息或别人的隐私直接截进去。通过 TestFlight 提交的反馈也会提供给 Apple；应用自己做的反馈入口属于另一条渠道。[3]

不想测了，怎么办？

进入 TestFlight 里该应用的信息页，选择 停止测试（Stop Testing）。如果已有正式版本，可以再去 App Store 下载或购买。只有测试版、尚未正式发行的应用，不一定有正式版可以换回。[3]

停止测试不等于删除你在应用里注册的账户；账户和云端数据要按应用自己的规则处理。

10. TestFlight 里的支付，会不会真的扣钱？

从 TestFlight 安装的应用，通过 Apple 应用内购买进行的测试交易走沙箱，不会真实扣款。这也包括通过 StoreKit 测试订阅。[3][10]

“沙箱”可以理解为购买流程的演练环境：应用可以读取商品信息、发起测试购买、恢复购买、处理交易通知，但不会因此产生真实销售收入。[10]

这里最容易误解的，是沙箱的范围。

不扣钱，不代表正式版永久免费

Apple 明确说明，测试期间的应用内购买不会作为购买记录带到 App Store 正式版。不要向测试者承诺“现在点一次，正式上线后永久有会员”。[3]

开发者如果另外决定赠送应用账户权益，那是自己的业务安排，不是 TestFlight 自动提供的规则。

测试订阅的时间，也不等于真实计费时间

对自动续期订阅，Apple 当前的 TestFlight 测试者说明是：不论原订阅周期长短，测试时按每天续订，在一周内最多续订六次。使用沙箱账户的高级控制还可调整续订速率；不要把其他沙箱场景的“五分钟”“十二次”等参数直接套用到普通 TestFlight 测试。[3][10]

这些加速规则用于测试续订和到期，不能当作正式用户的账单周期。

只有 Apple 购买通道自动进入沙箱，不是整个应用

一个 TestFlight 应用仍可能：

• 连接正式服务器，修改真实记录；
• 发送真实邮件或消息；
• 删除真实账号或数据；
• 打开真正收款的网页；
• 使用并非 Apple 应用内购买的付款方式。

网页支付、Apple Pay 和 StoreKit 应用内购买不是同一件事。不能因为应用来自 TestFlight，就认为网页结账或现实业务一定不花真钱。开发者需要单独配置测试数据、服务器和其他支付环境。[10]；应用系统边界说明

每个测试者都要创建沙箱账号吗？

不需要。普通 TestFlight 安装和购买测试可以使用日常 Apple 账户。[10]

只有需要清空购买历史、调整高级测试设置等控制时，开发者才需要按 Apple 文档配置 Sandbox Apple Account。高级步骤可能涉及退出“媒体与购买项目”，影响设备上已购内容的访问；这不是普通测试者安装前必须做的事，更不应该随便让人退出整台设备的 iCloud。Apple 建议考虑使用专门的测试设备。[10]

如果购买显示成功，但应用没有解锁功能，仍要向开发者反馈。商品配置、交易验证、权益发放、恢复购买和续订处理都需要正确实现。沙箱购买成功，不是正式支付、收入到账和全部订阅逻辑正确的证明。

11. TestFlight 有哪些限制？

表格较宽时可左右滑动；键盘用户可聚焦后使用方向键。

90 天到期后，重新发邀请有用吗？

没用。期限属于构建，不属于某个测试者。晚加入的人不会重新得到完整 90 天。到期后测试版不能继续打开，开发者需要提供新的有效构建。[3]

如果希望测试不中断，应在旧构建过期前上传、分发新构建，并提醒大家更新。新构建有自己的期限，不会延长旧构建的寿命。

能不能长期靠 TestFlight 卖应用或卖名额？

不要把它当作绕过正式发行的销售渠道。

Apple 审核准则 2.2 要求测试应用遵守审核规则，并以公开发行为目的；也禁止以任何形式的对价交换 TestFlight 测试分发，包括作为众筹奖励。简单说，不能把“付钱进群才能拿到测试版”当作正常的 TestFlight 分发方案。[14]

12. 常见问题：别人为什么安装不了？

表格较宽时可左右滑动；键盘用户可聚焦后使用方向键。

这些是排查方向，不是看到一句报错就能确定根因。[3][5][6][11]

特别提醒：后台的绿色“测试中（Testing）”也可能只是内部组在使用。要判断外部用户能不能安装，必须核对目标外部组、具体构建和该组的可用状态。[11]

“准备提交（Ready to Submit）”“等待审核（Waiting for Review）”“测试审核中（In Beta Review）”“准备测试（Ready to Test）”也不是同一个阶段。尤其是准备测试，仍可能需要添加测试者或完成手动通知。[11]

13. 开发者去哪里看反馈，怎样继续发新版？

进入 应用 → 你的应用 → TestFlight → 反馈（Feedback），可以查看 截图（Screenshots）与 崩溃（Crashes），并按版本、设备等条件筛选。反馈是否可从应用内提交还受分组设置影响。[12]

先处理能复现的问题，再进行下一轮：

1. 修正问题，使用新构建号打包上传。
2. 等待处理，完成必要合规。
3. 把新构建加入目标组，完成必要外部审核。
4. 更新测试重点，按设置通知测试者。
5. 请目标组中的人确认实际安装了哪个版本和构建，并重试原问题。

上传记录、分组名单和审核批准都很重要，但最终还要确认：目标人群确实装上了目标构建。

只发一个内部测试截图，不能证明所有外部用户也都能安装；模拟器里能运行，也不能替代设备上的安装结果。

14. 怎样结束测试，或者正式上架？

先看你想停止哪一件事：

• 不再招募新用户：停用外部组的公开邀请链接。
• 调整谁能收到哪些构建：管理测试者、分组和构建分配。
• 停止某构建的新安装：进入构建详情，选择 使构建过期（Expire Build）。不要把它理解成远程删除所有手机上的应用或擦除云端账号。[6][13]
• 正式发行：准备 App Store 正式版本需要的资料，选择合格构建，另行提交正式审核。[1][2]

已经通过普通 TestFlight 上传的合格构建，可以被选择用于正式提审；不一定仅仅因为要上架就必须重新打包。但实际代码变了要上传新构建，“仅限内部测试”的上传也不能用于正式发行。[2][5]

TestFlight 审核通过，不会自动发布到 App Store。反过来，正式版上架也不会自动结束仍有效的测试版；需要分别安排测试的结束和用户的切换。[1]

15. 发给第一批测试者的话，可以直接这样写

想请你帮忙试一下［应用名称］的早期版本。

先从 App Store 安装 Apple 官方 TestFlight，再在 iPhone 上打开［实际邀请链接］，接受邀请并安装。

本轮想请你重点试：［一到两个具体任务］。支持设备和系统：［实际要求］。

这是测试版，可能有问题，重要资料请先备份。遇到异常，可以在 TestFlight 的“发送测试反馈”里告诉我做了什么、预期是什么、实际发生了什么，最好附上截图和版本号。

把方括号替换成真实信息。确定目标外部组里的构建确实可安装后，再发送，不要先群发一个还在等待审核的链接却称它已经可用。

发布前，最后检查这十项

• □ 我按账号权限选择了内部或外部测试，没有为了省事给人过度权限。
• □ 目标构建已经处理完成，没有未解决的分发阻碍。
• □ 目标组确实包含这个构建。
• □ 必要的外部审核已通过，需要的通知也已发送。
• □ 我已检查所用的邀请方式：邮件邀请发给了正确的人；如果使用公开链接，它已启用且有名额。目标设备和系统符合要求。
• □ 测试描述、反馈邮箱、测试重点都真实且有用。
• □ 测试者知道这是测试版，也知道它可能替换正式版。
• □ 我分清了沙箱购买与真实服务器、网页支付和现实操作。
• □ 我看过构建的过期时间，并安排了后续更新。
• □ 目标人群中有人确认实际装上了目标构建，而不只是打开了邀请网页。

第一次把应用发出去，真正的终点不是“上传完成”。而是对的人装上了对的版本，知道要试什么，也知道如何把问题反馈给你。

来源与进一步阅读

以下资料于 2026 年 9 月 17 日核实。历史节点使用同期报道或 Apple 当年公告；现行规则以 Apple 官方帮助为主。操作界面可能随语言和版本变化。