这问题我之前帮团队排查过，核心原因其实是Firebase App Distribution判断版本新旧的逻辑和你预期的不一样：它优先依据内部构建号（Build Number），而非你对外展示的语义化版本号。

你给出的两个版本：

• 旧版本：2021.6.4 (5) → 括号里的5是构建号（对应iOS的CFBundleVersion、Android的versionCode）
• 新版本：2021.6.5 (4) → 括号里的4是构建号

Firebase在做版本高低判断时，会优先解析这个纯整数的构建号——因为这是移动端系统用来区分版本先后的核心标识，要求必须严格递增。虽然你的显示版本号2021.6.5比旧版的2021.6.4高，但构建号4比旧版的5小，所以Firebase会判定这个新版本是“降级”版本，把已安装的旧版放在顶部。

要避免这种情况，核心就是把构建号的管理规则落地：

• 严格保持构建号递增：不管显示版本号怎么调整，每次发布新版本时，构建号必须比上一个已发布版本的数值大，绝对不能回退。比如这次发布2021.6.5，构建号应该设为6或者更高，而不是4。
• 统一版本号规范：制定明确的规则，比如显示版本号遵循语义化版本控制，构建号采用自增整数（比如每次发布+1，或者关联发布次数），从根源上避免显示版本号升级但构建号下降的矛盾。
• 发布前做校验：上传到Firebase之前，手动核对当前版本的构建号是否大于所有已发布版本的构建号。如果有CI/CD流程，可以加一步自动校验，比如拉取Firebase已发布版本的构建号列表，和当前版本对比，不满足递增就终止发布。
• 可选：让构建号和显示版本号关联：比如让构建号的数值和显示版本号的补丁版本对应（比如2021.6.4对应构建号4，2021.6.5对应5），或者用构建号记录总发布次数，这样能减少出错概率。

内容的提问来源于stack exchange，提问作者Karsten Silz