# 生产发布检查清单

按发布前、灰度中、异常时逐项检查，保留可执行的恢复路径。

## 发布前，先完成这五项 {#before-release}

| 检查 | 完成证据 |
| --- | --- |
| 原生兼容 | 未修改依赖、权限或运行时；目标安装包已上传 |
| 内容正确 | `.ppk` 来自正确分支，关键页面真机验证通过 |
| 目标正确 | 预检中的应用、渠道、原生版本与比例均符合计划 |
| 可追溯 | `.ppk`、sourcemap、提交号和投放 ID 已归档 |
| 可恢复 | 上一个稳定包仍可投放，已确认恢复目标 |

## 优化原生包体积 {#native-size}

保留并上传实际分发给用户的安装包。删除未使用的图片和依赖后，重新构建、测试再分发。

### iOS

保存 Xcode Archive 及导出的 IPA，确保上传与分发来自同一次构建。不要为了减小上传文件而重新编译另一份包。

### Android

- `crunchPngs false`（见[安装配置](/docs/getting-started#android)）：保证构建间资源字节稳定，差分才有意义。
- 用 `apkanalyzer` 检查重复资源与未用到的 so 库。
- 上传安装包用已签名的 release APK；Debug 包与 release 包不要混用。

## 控制热更包体积 {#ppk-size}

`.ppk` 只含 JS bundle 与资源，体积大头通常是图片：

- 大图走 CDN、按需下载，不要打进 bundle；
- 新增图片资源是热更包膨胀的第一原因，发版前过一遍资源 diff；
- Hermes 开启时 CLI 自动复用基线字节码（`--hermesBase auto`），补丁通常显著小于全量；补丁收益不足时平台自动回退全量，无需人工干预。

## 逐步扩大更新范围 {#rollout-discipline}

- **先测试**：用内部测试渠道（见[渠道发布](/docs/channels#practices)）验证每次发布，再进生产渠道灰度。
- **逐步增加**：10% → 30% → 100%，每档停留一段时间观察[版本健康度](/docs/analytics#version-health)。
- **发现异常**：回滚率或失败率异常时先[停止继续发布](/docs/console#stop)，检查原因。
- **记录操作**：每次放量都在投放管理中留下清晰记录，出问题能立刻对准"哪一步开始坏的"。

## 应用商店审核期 {#store-review}

保持审核包行为与提交说明一致，不用远程更新隐藏功能或绕过审核。渠道隔离只能控制分发，不能保证审核通过。发布前核对[Apple 官方审核指南](https://developer.apple.com/app-store/review/guidelines/#software-requirements)及目标商店规则。

## 回滚预案 {#rollback-plan}

- 每次发布前确认上一版本仍在版本列表中且可投放（历史包可随时作为新的全量投放，见[回滚](/docs/publish#rollback)）。
- 团队内约定告警阈值：回滚率、下载失败率谁来看、多快响应。
- 热更新版本崩溃时 SDK 自动回退上一可用版本——确保你的关键初始化逻辑与[健康确认](/docs/integration#health)配置匹配，否则崩溃保护可能被过早的自动确认跳过。

## 归档习惯 {#archive-habits}

- `publish --sourcemap` 归档每次发布的 sourcemap，线上堆栈可随时还原（见[JS 报错监控](/docs/errors#symbolicate)）。
- `--name` 使用可追溯的命名（如工单号或 CI run id），版本列表一目了然。