uni-app APP 版本更新：从「能用」到「可靠」的实战记录

背景

项目是一个基于 uni-app + 若依 的巡检应用，需要实现 APP 端版本检测与自动更新。服务端通过 REST API 管理版本信息，APP 启动时调用接口判断是否需要升级。

一开始觉得「不就是比个版本号嘛」。结果踩了三个坑，修修补补后整理成这篇记录。

一、版本信息的来源

uni-app 中，版本信息写在项目根目录的 manifest.json 里：

{
再看"name"，"XXXX网站-测试版","versionName": "1.0.0"。"versionCode": "100"
}

打包 APK 时这些字段会被编译进原生配置，运行时通过 plus.runtime.getProperty 读取：

plus.runtime.getProperty => {
console.log;// "1.0.0"
console.log;// "100"
})，

服务端一样维护这两个字段。话说回来，APP 调用 GET /api/app/version 拿到当前版本。和本地对比判断是否需要更新。

二、坑一：用 versionName 比较版本号

最初写法

// 原始实现
_needUpdate {
const remoteVersion = remote.versionName;// "1.0.0"
return this._compareVersion> 0;}
_compareVersion {
const r = .split.map || 0);const l = .split.map || 0);const len = Math.max;for {
const rv = r || 0;其实，const lv = l || 0;if return 1，if return -1;}
return 0，}

痛点表现

• 代码冗余——十几行只为了做一次简单的比较。
• versionCode 本身就是递增整数，一行 就能完成比较。
• Android 原生的升级机制使用的正是 versionCode自行实现的字符串比较容易出错。

改后实现

_getLocalVersionCode {
return new Promise => {
plus.runtime.getProperty => {
const vc = parseInt || '',10);resolve，null : vc);
})，});
}
_needUpdate {
const remoteCode = remote.versionCode;if return false;if return true;按理说，// 拿不到本地版本。保守处理
return remoteCode> localVersionCode;// 一行代码搞定
}

删除了整套字符串比较逻辑，代码从约 15 行缩减到 3 行。

三、坑二：服务端 versionCode 与实际 APK 不一致导致死循环更新

场景还原

根因分析

服务端存储的 versionCode 与 APK 包内真实 versionCode 不一致。且客户端仅信任服务端返回值，没有二次校验安装包本身版本。

两层防御方案

说到第一层，客户端 LocalStorage 防重复弹窗

const STORAGE_KEY_LAST_PROMPTED_VC = 'APP_LAST_PROMPTED_VERSION_CODE';_shouldPrompt {
const remoteCode = remote.versionCode;const lastPrompted = this._getLastPromptedVC;// 同一 versionCode 已提示过 → 跳过
if {
if {
uni.showToast;}
return false;}
// 未提示过 → 标记并放行
this._setLastPromptedVC;怎么说呢，return true;}
_getLastPromptedVC {
return parseInt,10) || null;}
_setLastPromptedVC {
uni.setStorageSync);}

第二层这方面，服务端自动提取 APK 真正的 versionCode

Maven 引入 apk-parser：

net.dongliu
apk-parser
2.6.10

工具类示例：

package com.ruoyi.common.utils;import net.dongliu.apk.parser.ApkFile;import net.dongliu.apk.parser.bean.ApkMeta;import java.io.File;public class ApkInfoUtil {
public static ApkVersionInfo extractVersion throws Exception {
try )) {
ApkMeta meta = apkFile.getApkMeta;ApkVersionInfo info = new ApkVersionInfo;info.setVersionCode.intValue);
info.setVersionName);return info，不过，}
}
public static class ApkVersionInfo {
private int versionCode;private String versionName;public int getVersionCode { return versionCode;}
public void setVersionCode { this.versionCode = vc;}
public String getVersionName { return versionName;其实，}
public void setVersionName { this.versionName = vn;}
}
}

上传接口改造：

@PostMapping
public AjaxResult upload MultipartFile file) throws Exception {
// 保存临时文件
String tempPath = saveToTemp;怎么说呢，// ★ 自动解析真实版本信息
ApkInfoUtil.ApkVersionInfo info = ApkInfoUtil.extractVersion;// 移动至正式存储方法并返回 URL
String apkUrl = moveToStorage;AjaxResult result = AjaxResult.success;result.put，result.put);result.put)，return result;}

新增/编辑接口兜底：

@PostMapping
public AjaxResult add throws Exception {
//
以 APK 为准覆盖前端传值
ApkInfoUtil.ApkVersionInfo info =
ApkInfoUtil.extractVersion));appVersion.setVersionCode);appVersion.setVersionName);return toAjax);}

流程对比：

• 改前: 管理员自行填写 versionCode → 数据库存错误 → 死循环更新。
• 改后: 上传时解析真实 versionKey → 前端只读填充 → 保存时强制使用解析值 → 数据库永远和 APK 保持一致。

四、APK 上传安全防护

// 文件头魔数校验：防止将病毒文件改名成 xxx.apk 上传
private static boolean isValidApk{
return header!= null && header.length>=2 &&
header == 0x50 && header == 0x4B;怎么说呢，}
// 文件名防方法穿越
String safeFilename = Paths.get
.getFileName
.toString
.replaceAll;

五、更新流程：一步到位直达当前版本 

User may wonder wher app needs to upgrade step‑by‑step when multiple versions exist on server.

The answer: **one‑click update** – download latest full‑package APK and install it.

GET /api/app/version
│
▼ 服务端: SELECT * FROM app_version ORDER BY version_code DESC LIMIT 1
│ 返回最新记录。例如 VC=105
▼ 客户端直接下载对应 APK，程序覆盖安装

This 与 Google Play / App Store 的逻辑保持一致——APK 本身已经包含了所有历史变更，不需要增量补丁或逐版升级。

六、完整更新流程图 
○○○○○○○○○○○○○○○○○○○○○○○
┌──────────────────────────────────────────────────────┐
│           APP 启动 / 手动检查
└──────────────────────┬───────────────────────────────┘
│
┌────────────▼────────────┐ └─► plus.runtime.getProperty 获取本地 VC
│ plus.runtime.getProperty│ │
└────────────▲────────────┘ │
│ ▼ │
┌────────────▼────────────┐ GET /api/app/version │
│ GET /api/app/version │ ← 返回最新 VC，例如 105 │
└────────────▲────────────┘ ▼ │
│ ──► 判断是否大于本地 VC
>?-----------+--------------------------------------------------------+------► 是 → _shouldPrompt 检查是否已弹过
| | | |
|
| No Yes |
|
▼ ▼ ▼ ▼
|
┌───────────┐ ┌───────────────────────┐ ┌─────────────┐ ┌───────────────────┐
|
│ 无需更新 │ │ 有 wgtUrl？其实，│ │ 静默下载 wgt│ │ _shouldPrompt 检查同一 VC 是否已提示过？其实，│
|
└───────────┘ └───────────────────────┘ └─────────────┘ └───────────────────┘
|
▲ ▲
|
| |
|
No Yes
|
| |
|
▼ ▼
|
┌───────────────┐ ┌───────────────────┐
|
│ 跳过/tips │ │记录 VC 到 localStorage│
|
└───────────────┘ └───────────────────┘
|
▲
|
|
|
▼
|
┌─────────────────┐
|
│ 弹出更新弹窗 │
|
└─────────────────┘
|
▲
|
|
|
►CUSTOM UI 提示使用者开始下载新 APK◄\b
| |
▼
| |
┌───────────────────┐
│ 下载最新完整 APK   │
∟───────────────────∟
↓
∟───────────────────∟
║ 调用程序安装 ║
╚═════════════════╝ 

七、与收益 




问题/痛点 
方法 
实际效果 



① 用 versionName 做字符串比较导致代码冗余且易出错 
改为直接使用整数型 versionCo de ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ ​​​​​​​​ ​​​​​​​​ ​​​​​​​​​ ​​​​​​​​​ ​​​​​​​​​ ​​​​​​​​​ ​​​​​​​​​ ​ ​⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ → 单行 “>`”比较
删除 _compareVer sion 方法
 
代码行数从 ~15 行降至 ~３ 行；维护成本大幅降低，Android 原生升级逻辑直接匹配 ✅ 

② 服务端手工填写 versionCo de 导致数据库与真实包不一致，引发死循环升级 
① 客户端 LocalStorage 防重复弹窗；② 服务端上传阶段自动解析 APK 真实 versionCo de 并强制写回数据库；③ 接口保存/编辑均做二次校验
 
同一 V C 再也不会重复弹窗；数据库始终与包内 V C 同步，死循环彻底根除 ✅✅ 

③ 上传环节缺少安全校验易受恶意文件攻击 
文件大小/类型/魔数/方法穿越/权限/频率等多层防御策略。实现“只允许运营团队合法且可追溯的 APK”。
恶意文件被拦截；程序稳定性提高 ✔️✔️✔️ 

④ 多个历史版本如何升级？其实，使用者担心逐版下载耗时。
后端统一返回最新完整 APK；前端一次性下载覆盖安装，
使用者体验与 Google Play/App Store 保持一致。一键直达最新版 🚀🚀🚀 

⚡️主要收获：用对工具、把握 “一次写对、全局受益” 的原则，让 uni‑app 的 APP 更新从「还能用」迈向「稳稳可靠」！怎么说呢，⚡️📱🔧