uni-app App端不支持“增量资源热更新+版本回滚”一体化操作，因wgt包为全量快照、无版本链，plus.runtime.install()仅执行普通安装且不记录历史，回滚需服务端提供指定旧版wgt地址并确保versionCode递增。
uni-app App端不支持“增量资源热更新 + 版本回滚”一体化操作。所谓“增量热更新”，本质仍是 wgt 包替换；而 wgt 包本身是全量资源快照，不是 diff 补丁——它没有内置版本链或回退能力。真要回滚，必须手动触发上一个 wgt 包的重新安装。
为什么 plus.runtime.install() 无法自动回滚
wgt 热更新机制只负责「下载 → 解压 → 覆盖 uni-app 的 static、pages、components 等资源目录」，不记录历史版本、不维护本地 wgt 缓存索引、也不校验版本递增关系。调用 plus.runtime.install() 时传入任意合法 wgt URL（哪怕指向旧版），它都照装不误——但这不是“回滚”，只是另一次普通安装。
- 服务端若未保留旧版 wgt 文件，客户端根本无法获取回滚包
-
plus.runtime.getProperty()只能读取当前运行的 wgt 版本号（即manifest.json中的versionName），不暴露已安装过的其他版本 - Android/iOS 均无系统级 wgt 版本管理，
plus.runtime.restart()后加载的就是最后一次成功 install 的资源
实现可回滚的 wgt 更新，关键在服务端设计
客户端无法自发回滚，必须依赖服务端提供明确的“目标回滚版本”和对应 wgt 地址。常见可靠做法：
- 后端接口（如
/update/check）返回字段中增加rollbackVersion和rollbackWgtUrl，仅当检测到当前 wgt 异常时才填充（例如通过上报错误码或心跳失败触发） - 客户端在
onLaunch或异常捕获逻辑中主动请求该回滚接口，而非仅依赖常规更新检查 - 确保每个 wgt 包文件名含唯一标识（如
UNI832D722_1.0.1.wgt），且服务端长期归档所有历史 wgt，禁止覆盖删除 - 回滚安装前，建议先
uni.clearStorage()清除可能残留的旧版缓存数据，避免资源与逻辑不一致
manifest.json 的 versionCode 必须严格递增，否则回滚会失败
很多人以为回滚就是装个旧版 wgt，但 Android 端 plus.runtime.install() 内部会校验 versionCode：若新包 versionCode ≤ 当前已安装 wgt 的 versionCode，安装直接静默失败，控制台无报错。
- 回滚包的
versionCode不能真的“变小”，必须人为设为比当前值更大的数（例如当前是105，回滚包设为106，并在服务端标记其为“rollback-1.0.1”） -
versionName可保持真实语义（如仍写"1.0.1"），不影响展示，但versionCode是纯数字且不可逆 - HBuilderX 打包时读取的是
manifest.json，改完必须重新生成 wgt，不能手动重命名已有文件
真正麻烦的不是技术实现，而是 wgt 回滚缺乏原子性：资源覆盖了，但本地 storage、SQLite 数据、甚至 plus.cache 都还留着新版逻辑产生的脏数据。每次回滚，都得同步清理这些状态——而这部分逻辑，没有任何 API 能自动帮你做。
