先说一个按常见情况拼出来的场景，不是哪位真实客户。包传完，屏幕右下角弹出一行绿色的成功提示，他端起杯子去接了杯水，回来刷新 App Store Connect，构建版本那一栏还是空的。他以为网络断了，又传一遍。第二遍还是空的。到第五遍，他开始怀疑苹果的服务器是不是出了问题。
这个场景里，最容易被忽略的一句话是：上传成功，说的是文件到了，不是说这个包已经能被提交。
上传成功，只是文件到了
把一个 iPA 想成一件快递。上传工具做的是把包裹送到苹果的仓库门口，签收单打了勾，这一步就算完成。仓库还要开箱、过安检、登记入库，走完这些，你的账号里才会出现一个可以挑选的构建版本。
开箱查的东西不少：签名证书和描述文件对不对得上，包里的权限说明全不全，用到的第三方组件有没有踩线，包本身的版本信息有没有填齐。任何一项过不去，包就停在处理阶段，甚至直接判为无效。
所以那条成功提示只证明了一件事：传输链路没问题。它证明不了包能过安检。
这一步想通了，后面很多动作就不会白做。
卡住的地方，常见在构建号
同一个版本号下面，构建号是要往上走的。版本号可以一直停在 1.0，构建号得是 2、3、4 这样递增。
麻烦在于，很多打包流程不会自动加这个数。改完代码点打包，版本号没动，构建号也没动，出来的还是同一个包。你把它传十遍，在苹果那边就是同一件东西到了十次，不会多出十个构建版本。
很常见的一幕是：从晚上八点传到十点，页面每次都说成功，构建版本始终只有一个旧的。他以为是网络慢，换了三个网络。真正的原因很简单，构建号从第一遍起就没变过。
这里有个反直觉的地方：传得越勤，越容易把自己绕进去。每传一次，邮箱里就多一封通知，真正说明原因的那封，反而被压到了下面。
所以第一件事不是重传，是把构建号翻出来看一眼。它和上一次相比，动了没有。
还有三种情况，看起来也像没传上去
包还在处理的时候，页面怎么刷新都看不到它。包越大，处理越久。刷新得再快，也不会让苹果那边快一秒。这时候唯一该做的是等，顺便看一眼上传记录里的状态，而不是接着点上传。
账号不对的时候，也是一样的空。上传用的账号，和登录后台看构建版本的账号，有时不是同一个。团队分工细一点，负责打包的人拿到的是上传权限，负责提交的人登进去却看不全。页面看起来像空的，其实是权限把东西挡住了。
包被判无效的时候最安静。签名不匹配、权限描述缺失、塞了不该塞的组件，都可能走到这一步。它不会在页面上大声报错，通知一般只发到上传账号的邮箱里。很多人不看邮箱，只盯着后台刷新，自然什么都等不到。
这三种情况的共同点是：问题都不在“传”这个动作上。再传多少次，也只是把同一个错误重复一遍。
我现在的排查顺序
第一步，看构建号动没动。没动，先改这个数，别的都往后放。
第二步，看上传记录和状态。好的工具会留下每次上传的时间和结果，能一眼看出是传完了在等处理，还是根本没进去。
第三步，看账号权限。把上传账号和提交账号对齐，或者确认当前账号在团队里的角色够不够。
第四步，翻邮箱。搜索应用名或者包名，看看有没有一封说构建版本无效的邮件。那封邮件里通常写着具体原因，比在后台猜快得多。
这四步走完，绝大多数“构建版本为空”的情况都能落到一个具体位置上。剩下那些真正复杂的，才需要动到证书、描述文件甚至打包配置。
最不该做的一件事
每隔两分钟点一次重传。
同一个包重传，不会改变处理结果，只会让上传记录变长。更麻烦的是，它会把真正有用的那封通知埋掉。等到你终于想起来看邮箱，前面几十封重复的“上传成功”已经把那封“构建版本无效”挤得找不着了。
按一个常见情况测算：一个几十兆的包，传一次两三分钟，处理十几分钟。构建号没动的前提下，传十次，等于把同样的等待重复十遍，一个小时就没了，问题一步也没往前走。这个数字只是演示，实际时间因包的大小和网络情况而异。
什么时候该换个工具
如果你用的是 Windows，上传这一步本来就绕不开工具。网页端上传 iPA 到 App Store Connect，不用装 Xcode，也不用借一台 Mac；分片上传和断点续传能应付网络不稳的情况，传完会留下记录，出问题能回头查是哪一次、停在哪一步。它负责的是把包稳稳送进苹果的通道，构建版本能不能出来，仍然取决于包本身和苹果的处理。
这句话得说在前面，免得有人以为换了个上传工具，审核就会变松。
最后
下次看到“上传成功”四个字，先别把它当成终点。翻一眼构建号，等处理走完，再看构建版本那一栏。真要重传，也先把构建号改掉再传。
省下来的不是那几分钟，是你一遍遍刷新页面时的那点耐心。
需要上传 iPA 的话，可以从这里开始：https://www.chuxueyun.com/pages/ipaupload