一句话结论：用户在 App 里看到的是版本号，系统判断”能不能覆盖安装”看的是构建号。两个号在签名分发场景下要求都严格递增，填错一个，最直接的后果就是老用户装不上新包。

两个号各管什么

版本号，也就是 Version，是面向用户的，写法通常是三位数字，比如 2.1.0。它表达的是”这是第几个大版本”，用于沟通、用于客服对话、用于后台统计。

构建号，也就是 Build，是面向系统的。它可以是单个递增整数，也可以是多段数字。系统在判断同 Bundle ID（应用包名，App 的唯一标识）的两个包谁更新时，比较的是构建号。

两者可以一样，也可以不一样，但都必须满足一个条件：新版不能低于旧版。

严格递增这条规则是怎么判的

系统对构建号做的是分段的数值比较。以点号分隔，逐段比大小：1.9 小于 1.10，因为第二段 10 大于 9；2.0.0 大于 1.99.99，因为第一段就分出了胜负。

这正是最容易踩坑的地方——很多人把构建号当成小数看，觉得 1.9 比 1.10 大，于是从 1.9 直接跳到 1.10，结果系统认为这是降级，拒绝覆盖。

实践中更省事的做法是：构建号直接用单个整数，从 1 开始，每次加 1。这样不存在分段比较的歧义，也不需要解释规则。

填错之后会发生什么

第一种是覆盖安装失败。用户点安装，进度条走完提示”无法安装”，或者装完发现还是旧版本。这类反馈在客服口径里非常容易被误判成掉签——包是好的，证书是好的，只是构建号填小了。

第二种是数据不兼容。如果新版本的本地数据结构做了调整，而构建号不小心低于线上版本，部分用户会停留在旧数据结构上，等后面真正的新版本上去，就出现读取异常。

第三种是统计口径混乱。埋点把构建号和版本号一起上报，如果构建号来回跳，后台按版本分维度的报表会失效。

签名分发下要额外注意的三点

第一，重签不改号。只换签名、不改代码的包，构建号必须保持不变。一旦有人为了”好像更新了”去动这个号，就可能出现同一份代码两个构建号，用户那边覆盖逻辑混乱。

第二，多包并行要统一口径。同一款 App 如果有多个渠道包，构建号应该保持一致，靠渠道号而不是构建号区分，否则渠道之间互相覆盖。

第三，回滚要走高位。线上版本出严重问题需要退回旧版时，不能把构建号改回旧值重装，那样同样触发降级拒绝。正确做法是把旧代码重新打包，构建号继续往上加。

怎么自查

装好包之后，在设置里找到已安装的描述文件与应用信息，能看到当前构建号；用解压工具打开 IPA（iOS 安装包），读里面的 Info.plist（应用配置清单），也能看到 CFBundleVersion 字段。发包前把这两个值和上一版对一遍，三十秒能省掉一整天的客诉。

小结

版本号给人看，构建号给系统看，两者都要严格递增。构建号用单整数递增是最省事也最不容易出错的方案；重签不动号，回滚走高位。把这三条记住，覆盖安装这类问题基本不会找上门。

---

我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920　微信：A-mk5888）