热更新与整包更新需按场景区分：仅改name等基础字段且未动原生配置可热更新；新增权限、改android:name、升级SDK或uni-app编译器、修改uni_modules原生插件则必须整包更新。
热更新和整包更新不是二选一，而是必须按场景分开走；错用 wgt 更新原生模块或权限，App 会白屏或闪退，且无法回滚。
怎么判断该走热更新还是整包更新
关键看 manifest.json 里改了什么：
- 只改了
name、description、versionName、versionCode，且没动原生相关配置 → 可走热更新（.wgt） - 新增了
Android权限（如定位、后台运行）、改了android:name、升级了 SDK 或 uni-app 编译器版本 → 必须整包更新（.apk/ App Store URL） - 改了
uni_modules里的原生插件（比如集成极光推送、微信登录 SDK）→ 整包更新，热更新不生效
注意：versionCode 是纯数字（如 102），用于比大小；versionName（如 "1.0.2"）仅作展示，不能直接字符串比较。后端接口返回的也必须是 versionCode 数值，否则 iOS 侧可能因类型转换失败跳过检测。
热更新 wgt 包生成与校验要点
不要依赖 HBuilderX “发行 → 制作资源升级包” 一键生成——它默认打包根路径不对，容易漏 manifest.json 或错压子目录。
- 先执行
yarn build:app-plus（或npm run build:app-plus），输出目录如dist/build/app-plus - 进入该目录，确认存在
manifest.json且其versionCode已更新；再用 zip 命令从该目录**平级打包所有文件**：zip -r app.wgt . -x "*.DS_Store" - 重命名为
.wgt后，用unzip -l app.wgt | head -10检查：第一行必须是manifest.json，不是dist/build/app-plus/manifest.json - 上传前手动解压校验：打开
manifest.json，确认versionCode和你期望一致；否则 plus.runtime.install 会静默失败
plus.runtime.install 的 force 参数陷阱
force: true 看似省事，但它是双刃剑：
- 设为
true：跳过versionCode校验，哪怕新包versionCode更低也会强行覆盖 → 用户可能降级到有严重 bug 的版本 - 设为
false（默认）：要求新包versionCode > 当前 versionCode，否则回调直接进 error → 但错误信息是"Install failed: invalid version"，不提示具体原因 - 真实建议：服务端返回时就带
mustForce: false字段，客户端根据它动态传force；强制更新场景（如旧版 API 已下线）才设true，且必须配合弹窗强提示
另外，plus.runtime.install 成功后不会自动重启，必须显式调用 plus.runtime.restart()；iOS 上若未在 plusready 后调用，可能卡在白屏。
整包更新在 iOS 上的实际限制
iOS 无法直接下载安装 .ipa，只能跳转 App Store；但 Apple 对跳转链接审核极严：
-
itms-apps://itunes.apple.com/cn/app/id{appleId}已被弃用，真机上会 404；必须用https://apps.apple.com/cn/app/id{appleId} - 如果 App 还没上架（测试阶段），
appleId为空或无效，plus.runtime.launchApplication会静默失败，无任何回调 - 安卓侧不要硬写
market://，华为、小米、OPPO 等厂商市场 scheme 不统一；稳妥做法是后端返回一个通用跳转页 URL，由 H5 页面做 UA 判断后跳对应商店
最后提醒一句：热更新包体积超过 10MB 就该警觉——说明你误把大图、视频、字体等静态资源打进去了，这会导致低端机安装失败或内存溢出；这些资源该走 CDN 按需加载，而不是塞进 wgt。
