版本更新
本页说明微应用的版本号规范与更新机制。
版本号规范
manifest.json 的 version 字段遵循 semver 语义化版本规范，格式为 主版本.次版本.修订号（MAJOR.MINOR.PATCH）：
| 变更类型 | 版本位 | 示例 |
|---|---|---|
| 功能新增、体验优化 | MINOR +1 | 1.2.0 → 1.3.0 |
| 问题修复、小调整 | PATCH +1 | 1.2.0 → 1.2.1 |
| 破坏性变更（数据结构、设置项含义变化等） | MAJOR +1 | 1.2.0 → 2.0.0 |
版本号必须严格递增
平台通过版本号判断是否为新版本。每次提审的版本号必须大于当前已上架版本，否则不会被识别为更新。建议同时更新 manifest.json 与 package.json 的版本号保持一致。
更新流程
版本更新走与首发相同的提审流程，审核通过后新版本上架。
用户侧的更新
新版上架后，已安装用户由商店分发机制获得更新。
数据不会丢失
微应用的存储（xunlei.storage）与用户设置按微应用 ID 隔离持久化，版本更新不影响已有数据。但要注意：
settings[].type或options发生变化时，该项设置会回退到默认值（见清单文件 · settings）；- 存储数据的结构变化请在代码中做好兼容（如给序列化数据加版本字段）。
迭代建议
- 小步快跑：修复类变更及时发 PATCH 版本；
- 灰度验证：大改动先本地完整回归（含 zip 正式安装路径），再提审；
- 事件脚本的兼容：
onResolve等脚本的匹配规则变更会影响所有命中用户，调整匹配范围时谨慎评估； - 在日志中带上
xunlei.info.version，便于线上问题定位时区分版本。