你三天前提交了 build，App Store Connect 里状态还停在 Waiting for Review——没切到 In Review、Resolution Center 没消息、邮箱没邮件。Apple 的公开承诺是 90% 的提交在 24 小时内给出通过或拒绝的结论（这条承诺已在 2026 年 4 月 1 日对英国 CMA 正式生效）。那你的为什么超了？
**最快的答案：**截至 2026 年 6 月，队列确实在堵——2026 年初 iOS 上的全球发版量同比涨了约 80%，现在实际等待普遍要 24-72 小时，首版和敏感类目的提交会拖到 5-7 天以上。动手之前先做两件事：(1) 确认每个提交字段都是绿色状态；(2) 打开 Resolution Center，看有没有未回复的审核员消息。你这边的”静默阻塞”是唯一你能真正修的原因，其余都只是”等还是升级”的取舍——而最糟的操作是上传新 build，那会把你扔到队尾。
先把状态读对
App Store Connect 的状态很容易误读。截至 2026 年 6 月，各状态含义如下：
| 状态 | 在等谁 | 含义 |
|---|---|---|
| Waiting for Review | Apple | 已收到，审核员还没接手；此时还能改部分 metadata。 |
| In Review | Apple | 审核员正在审。 |
| Pending Developer Release | 你 | 已通过——需要你点 Release 才发布。 |
| Ready for Distribution | 没人 | 已通过且上线（原 “Ready for Sale”）。 |
| Unresolved Issues / Rejected | 你 | 审核标了问题，去 Resolution Center 回复。 |
| Metadata Rejected | 你 | 仅 metadata 问题；改字段并回复，不用重交 build。 |
如果你的状态不是 Waiting for Review 或 In Review，那球在你这边——直接跳到对应处理。只有真正超过下文时间窗的 Waiting for Review 才算”队列卡住”问题。
常见原因
按命中率排序。
1. 2026 审核积压
这是目前最可能的原因。2026 年 Q1-Q2 提交量激增，连小更新都常停 24-72 小时，高峰能到 5-7 天。Apple 的 “90% 在 24 小时” 是全年平均，不是对你这一周的保证。
如何判断：查 Apple System Status 页（看 “Developer ID” / “App Review” 那几行）和第三方追踪站如 appreviewtimes.com。如果近期提交普遍 3+ 天，就是系统性慢，不是你的 App 的问题。
2. 全新 App 第一版
新 App 第一次审核会多一道核验（开发者账号历史、身份验证、业务核验），更新版本没有。v1.0 预期大约是常规等待的 2-3 倍。
如何判断：App Store Connect → 你的 App。如果这是这个 App 记录下第一个提交的 build，把额外时间算进预期。
3. 提交触发了自动启发式
敏感 entitlement（HealthKit、Contacts 访问、background modes、location-always）、新的认证方式（去掉 Sign in with Apple、加新 SSO）、新的内购或订阅、儿童内容（Kids 类目）flag、类目变化（比如进 Medical 或 Finance）都可能把 build 路由进延长审核。
如何判断：把当前提交的 entitlements.plist、内购配置、类目和上一个通过版本 diff 一下。出现上面任一项就预期更慢。注意订阅/内购改动会和二进制一起审，可能拖住整个提交。
4. 审核员已分配但在等外部
有时 build 实际已在审，只是 UI 滞后；或审核员升级给了 Apple 内部团队（法务、隐私）在等回复。
如何判断：打开 Resolution Center 看有没有未读审核员消息。有就回复——你不回复，时钟不走。
5. 区域性审核员池
中国区提交、支付密集 App、政府监管类目的 App 可能被路由到更小的审核员池，周转不同。
如何判断：注意你主打的目标区域，以及你提交所用 Apple Developer Program 账号所在的区域。敏感区域和错位都会拉长时间线。
6. 提交其实没填完
漏答 Export Compliance、漏 Content Rights、隐私问卷没填完——这些会阻塞路由，而且某些流程下根本没有 Resolution Center 消息提醒你。
如何判断：打开 build，确认所有状态指示器都是绿的：Export Compliance 已答、Content Rights 已确认、App Privacy 已填完、Age Rating 已设。单个 Not Set 字段就能拖住整个提交。
需要收集的信息
- App Store Connect → 你的 App → App Review（或 Activity）里精确的提交时间戳。
- 当前状态（对照上面的表）。
- Resolution Center 全部消息，包括标记已读的旧 thread。
- 这是 v1.0 还是更新版本。
- 提交是否加了敏感 entitlement、新内购/订阅或类目变化。
最短修复路径
Step 1：核对提交完整性
App Store Connect → 你的 App → 当前提交版本，逐项确认：
- App Information：类目已设、隐私政策 URL 有效、联系方式齐。
- Pricing and Availability：至少选了一个地区。
- App Privacy：数据收集问题答完，“Saved” 时间较近。
- Export Compliance：已答（加密 Yes/No）。
- Content Rights：已答。
- Age Rating：按内容填。
- App Review Information：可用的 demo 账号、地区说明、联系人。
任何 Not Set 或漏填字段都可能静默拖路由。补这类字段是唯一可能让状态在几小时内动起来的”修复”。
Step 2：再查一遍 Resolution Center
App Store Connect → 你的 App → App Review → Resolution Center。点开每个 thread，包括已解决的，确认最近一条回复里没有未回应的问题。Apple 偶尔会加一条低紧急度留言，不发邮件但会暂停队列。
Step 3：对照基准时长
用 appreviewtimes.com、Apple System Status 页，或开发者社区（r/iOSProgramming、Apple Developer Forums）判断整体队列是否在变慢。如果近期中位数也是 3+ 天，那你的延迟是积压，不是你的 build。
Step 4：按窗口等待（2026 校准版）
下面的窗口对应 2026 的积压现状，不是 Apple 的最佳情况。按工作日算。
| 提交日 | 典型等待（2026） | 升级前等多久 |
|---|---|---|
| 周一-周三 | 24-72h | 5 个工作日 |
| 周四-周五 | 48-72h | 下周三 |
| 周末提交 | 48-96h | 周三 |
| 已知积压 / 高峰周 | 5-7 天 | 10-14 个自然日 |
多数攻略说错的关键点：**在 Waiting for Review 期间修改允许编辑的 metadata 不会让你重排队。**真正会把你扔到队尾的是上传新二进制、提交新版本、或把 build 撤出审核。所以如果你忍不住想”做点什么”，就改个描述——千万别重新上传。（注意：每个平台同时只能有一个提交在审，总共最多两个。）
Step 5：发一封礼貌的状态查询
过了等待窗口，用 Contact App Review 提交请求，选状态查询的主题。保持客观：
Submission ID: 12345
App: Acme Studio v2.7
Submitted: 2026-05-15 14:32 PT
Current status: Waiting for Review (6 business days)
Could you confirm whether this submission has been routed?
This release contains a critical fix for [specific user-facing issue].
Thank you.客观、具体、不提要求。只在真有具体、有日期的业务影响时才给业务上下文。
Step 6：真正紧急再申请 Expedited Review
用专门的表单：developer.apple.com/contact/app-store/?topic=expedite（也可在 App Store Connect 底部的 “Contact us” 进入）。Apple 只接受两类理由：关键 bug 修复（附在当前线上版本上复现的精确步骤），或时间敏感事件（附事件名、日期、你的 App 与该事件的关联）。截至 2026 年 6 月，因为请求量大，加急被批的概率变低，所以只留给真正的紧急情况——滥用会被吊销该权限。一旦获批，加急审核通常 6-24 小时内完成。
附具体证据：崩溃报告 URL（Sentry、Crashlytics）、用户在 App Store 评论里引用此 bug，或绑定具体日期的新闻稿。
怎么确认已经修好
- 在升级或补完缺字段后，状态在几小时内切到 In Review，再到 Pending Developer Release 或 Ready for Distribution。
- App Store Connect → App Review 里该提交的历史显示带时间戳的状态切换。
- 邮件确认审核结果（通过或拒绝）。
- 同账号后续提交都在典型时间窗内完成。
如果还是没修好
- 在你已开的 Contact App Review thread 上回复，附原工单号——不要新开 thread，那会丢历史。
- 仅当你确信提交被误处理时才提交 appeal（单纯延迟不算）。
- 通过 Apple 开发者活动预约 App Review Webex 咨询（30 分钟），问某个已知会拖审核的 entitlement 组合。
- 在 r/iOSProgramming 或 Apple Developer Forums 问问你这个具体的 entitlement 或类目组合是不是已知的慢路径。
- 考虑把新触发的功能放在 feature flag 后（默认关），让下次提交的审核面更小。
预防建议
- 非紧急更新提早提——2026 年按 5-7 个工作日预留缓冲。
- 每次提交都更新 App Review Information；过期的 demo 账号或漏地区说明几乎必然触发延迟循环。
- 风险改动（新 entitlement、新内购）和常规 bug 修复拆开提；混在一起的风险包会拖慢整个发版。
- 用 TestFlight beta 审核（通常更快）先验证 build，再升到 App Store 审核。
- 维护一份发版日历，避开 WWDC 周（6 月初）、每次 iOS major 发布后一周、12 月节日窗口。
常见问题
重交同一个 build 会让审核更快吗？ 不会。撤掉 build 再重新上传会让你作为全新提交排到队尾。改 metadata 文本字段不会重排队，所以非要做点什么的话就改描述——别重新上传二进制。
2026 年卡 “Waiting for Review” 5 天正常吗？ 对常规更新偏慢但在当前积压下不算反常；首版和敏感类目 5-7 天很常见。更新超过 7 个工作日、或 v1.0 超过 10-14 个自然日，才到了合理升级的时点。
改 App 描述或截图会重置审核吗？ 在 Waiting for Review 期间改允许编辑的 metadata 不会重置计时。截图和预览在进入 Waiting for Review 后通常不能改，而上传新二进制或撤出 build 确实会重启审核。
App 被阻塞了，为什么 Resolution Center 没消息？ 有些阻塞（漏 Export Compliance、App Privacy 没填完、Content Rights 没答）会静默卡住路由且没有消息。重新核对每个提交字段是否绿色——这是最常见的”看不见”的原因。
我的状态是 “Pending Developer Release” 不是 “Waiting for Review”，为什么没上线？ 这个状态意味着 Apple 已通过，在等你。打开版本点 Release this version（或设为自动发布）。Apple 那边没卡任何东西。
能看到我在队列里的位置吗？ 不能。Apple 不公布队列位置，提交也不一定按收到顺序审核，所以不存在”等下去会丢的名次”。