wgt热更新必须满足plus.runtime.version升级和服务端wgtUrl可访问两个前提，否则plus.runtime.install()静默失败；需通过HBuilderX发行→原生App→制作移动App资源升级包生成合法wgt包，且安装后必须调用plus.runtime.restart()才能生效。
uni-app 的热更新（wgt 包在线升级）能绕过应用商店，直接在 App 内完成前端资源更新，但必须满足两个硬性前提：plus.runtime.version 版本号已升级、且服务端返回的 wgtUrl 可访问。不满足任一条件，plus.runtime.install() 会静默失败，连错误日志都不抛——这是最常被卡住的地方。
怎么生成合法的 wgt 包
生成 wgt 不是“导出 zip”，而是 HBuilderX 内置的编译流程，它会校验 manifest.json 中的版本号并打包所有编译产物（static/、js/、css/、页面结构等），但**不会包含原生插件或 nativeplugins/ 目录下的内容**。
- 必须先修改
manifest.json里的versionName和versionCode，新值要严格大于当前设备上运行的plus.runtime.version（字符串比较，不是数值） - 菜单路径是：
发行 → 原生App → 制作移动App资源升级包，不是“制作 App”或“云打包” - 输出的
.wgt文件名默认为UNIxxxxxx.wgt（对应你的 AppID），不要重命名，否则plus.runtime.install()可能识别失败 - 本地测试时，把 wgt 文件放到 HTTP 服务器可访问路径下，比如
https://your.com/static/UNI832D722.wgt，确保能直接浏览器打开下载
如何让 plus.runtime.install() 真正生效
plus.runtime.install() 是触发安装的核心 API，但它只接受远程 URL，不支持本地临时路径或 base64；而且它在后台静默执行，失败时既不报错也不回调——你得靠 plus.runtime.getProperty() 主动验证结果。
- 调用前务必确认网络通畅，且 wgt URL 返回状态码是 200（常见坑：Nginx 配置没放开
.wgtMIME 类型，导致返回 404 或 403） - 不要在
onLaunch里立即调用，建议加个 1–2 秒延迟，等plus.runtime模块完全就绪（尤其冷启动时） - 安装后必须手动调用
plus.runtime.restart()才能加载新资源，否则仍运行旧代码 - 验证是否成功：安装后立刻查
plus.runtime.getProperty('version')，如果值已变成新版本号，说明 wgt 已生效；否则就是安装失败，大概率是版本号没变或 wgt 包损坏
服务端接口该怎么设计才不翻车
客户端发请求检测更新，服务端不能只比对一个字段。wgt 升级依赖的是「版本号递增 + wgt 文件存在」双重判断，少一个环节就会降级成整包更新甚至无响应。
- 客户端请求参数至少带两个：
name（App 名称或 AppID）、version（当前plus.runtime.version） - 服务端需查出目标版本对应的
wgtUrl，且该 URL 必须能直连下载（HTTP 状态码 200，Content-Type 为application/octet-stream） - 如果新版本涉及新增原生模块（如扫码、蓝牙），
wgtUrl应为空，改返回pkgUrl（apk/ipa 下载地址），强制走整包更新 - 别用时间戳或 hash 做版本标识，
plus.runtime.install()只认 manifest.json 里的versionName字符串
最容易被忽略的一点：iOS 平台不支持 wgt 热更新，plus.runtime.install() 在 iOS 上始终返回 false。如果你的应用要上架 App Store，这部分逻辑必须用 uni.getSystemInfoSync().platform === 'ios' 提前拦截，否则用户会看到“检测到更新”却无法安装，还以为是 bug。
