生产发布检查清单
按发布前、灰度中、异常时逐项检查，保留可执行的恢复路径。
更新于 2026-09-14
发布前，先完成这五项
| 检查 | 完成证据 |
|---|---|
| 原生兼容 | 未修改依赖、权限或运行时；目标安装包已上传 |
| 内容正确 | .ppk 来自正确分支，关键页面真机验证通过 |
| 目标正确 | 预检中的应用、渠道、原生版本与比例均符合计划 |
| 可追溯 | .ppk、sourcemap、提交号和投放 ID 已归档 |
| 可恢复 | 上一个稳定包仍可投放，已确认恢复目标 |
优化原生包体积
保留并上传实际分发给用户的安装包。删除未使用的图片和依赖后，重新构建、测试再分发。
iOS
保存 Xcode Archive 及导出的 IPA，确保上传与分发来自同一次构建。不要为了减小上传文件而重新编译另一份包。
Android
crunchPngs false（见安装配置）：保证构建间资源字节稳定，差分才有意义。用
apkanalyzer检查重复资源与未用到的 so 库。上传安装包用已签名的 release APK；Debug 包与 release 包不要混用。
控制热更包体积
.ppk 只含 JS bundle 与资源，体积大头通常是图片：
大图走 CDN、按需下载，不要打进 bundle；
新增图片资源是热更包膨胀的第一原因，发版前过一遍资源 diff；
Hermes 开启时 CLI 自动复用基线字节码（
--hermesBase auto），补丁通常显著小于全量；补丁收益不足时平台自动回退全量，无需人工干预。
逐步扩大更新范围
先测试：用内部测试渠道（见渠道发布）验证每次发布，再进生产渠道灰度。
逐步增加：10% → 30% → 100%，每档停留一段时间观察版本健康度。
发现异常：回滚率或失败率异常时先停止继续发布，检查原因。
记录操作：每次放量都在投放管理中留下清晰记录，出问题能立刻对准"哪一步开始坏的"。
应用商店审核期
保持审核包行为与提交说明一致，不用远程更新隐藏功能或绕过审核。渠道隔离只能控制分发，不能保证审核通过。发布前核对Apple 官方审核指南及目标商店规则。
回滚预案
每次发布前确认上一版本仍在版本列表中且可投放（历史包可随时作为新的全量投放，见回滚）。
团队内约定告警阈值：回滚率、下载失败率谁来看、多快响应。
热更新版本崩溃时 SDK 自动回退上一可用版本——确保你的关键初始化逻辑与健康确认配置匹配，否则崩溃保护可能被过早的自动确认跳过。
归档习惯
publish --sourcemap归档每次发布的 sourcemap，线上堆栈可随时还原（见JS 报错监控）。--name使用可追溯的命名（如工单号或 CI run id），版本列表一目了然。