# 应用发布前，哪些检查与平台有关

原文: https://yishto.com/learn/application-platforms/application-release-and-maintenance/

作者: [Yishto](https://yishto.com/about/)

把移动、桌面和扩展发布拆成构建、安装、提交与审核状态，制定产物、权限声明、可信更新和回退验收。

首次发布: 2026-11-10
内容更新: 2026-11-10

构建成功说明工具链产生了产物，安装成功说明设备接受了它，审核通过则是分发渠道的另一项判断。三者不能混写为“应用已发布”。本课为同一组教学功能建立移动、桌面和扩展程序的发布记录。

案例只使用合成数据和测试环境。准备一个离线阅读功能、一次数据迁移和一个可恢复的更新错误，验证候选版本。具体账号资格、费用和审核时间查各平台当前要求，不推测统一门槛。

## 一个候选版本对应明确产物

版本记录包含产品版本、构建标识、源码提交、依赖锁定、目标系统与产物校验值。相同展示版本可以有不同构建，安装测试要能定位实际文件。不要测试一个开发包后上传另一份未经验证的构建。

记录状态至少区分构建、验证、内部安装、提交、处理中、待审核和渠道可用。每项有实际证据与失败原因，上传完成不能跳过处理与审核。后台服务部署另有自己的版本与接口兼容记录，客户端安装不自动更新服务器。

产物应含全部资源并连接正确测试或正式环境。调试日志、示例账号与未使用权限在打包前检查，秘密进入受限存储和构建机制，不放在客户端代码、公开文章或发行附件中。

## 移动平台检查什么

Apple的上传说明使用bundle ID与版本关联应用记录，构建字符串区分构建。通过当前支持的工具上传后还需要处理，随后才进入测试分发或审核流程。工具与SDK支持随政策变化，发布时核对实时页面，不能只沿用早先可上传的Xcode版本。

Android要区分调试和发布产物，配置签名、版本与目标SDK，并检查应用市场的当前要求。签名凭据有长期更新意义，保管与备份需要明确负责人和受限权限。不要把构建机临时生成的身份误当成可以随意替换的生产签名。

两种平台都测试首次安装和从旧版本升级。权限声明与实际行为对应，拒绝权限仍有可用路径。隐私说明应描述实际读取、存储和上传内容；没有实现的数据删除不能写成已经支持，涉及账户时还要验证相应恢复与删除流程。

## 桌面与浏览器扩展的差别

桌面应用验证目标系统架构、资源路径、权限与安装流程。Electron还要持续维护Chromium、Node与依赖的安全更新，重新核对renderer隔离和IPC授权。签名、安装和可信更新属于不同问题，不能因为文件下载成功就信任执行。

Chrome扩展上传包后填写列表、隐私和分发信息，再提交审核。manifest声明的权限应与单一用途一致。开发模式能加载扩展不表示商店允许分发；公开包中的逻辑应符合当前政策，不能靠下载远程脚本绕开包审查。

可延期发布等渠道功能要按当前控制台使用，不虚构时限。审核拒绝后记录具体原因、修改对应产物并重新验证，不能反复上传同一个问题版本。截图和介绍反映实际功能，不把测试计划描述成已有功能。

## 按顺序准备候选版本

先冻结候选源码与依赖，建立版本记录；再执行工程已有的相关检查，构建目标平台产物。保存构建日志，检查打包资源、环境端点与权限列表。这里描述读者要执行的流程，不声称本课已构建任何平台包。

随后在干净环境首次安装，用教学数据走核心路径。保留一份旧版本数据，升级候选版本并检查迁移。再关闭网络测试离线内容、重新打开验证状态，模拟权限拒绝和接口失败。模拟器结果标记为模拟器，未做真机测试的项不能填已验证。

确认产物与记录一致后进入内部测试分发，收集可复现问题并修复。最终提交前复核渠道材料与实际权限，上传同一候选产物。观察渠道状态，只有确认可用后再宣布该渠道发布完成。

## 离线就绪检查的边界

下面Python示例检查四个指定字段，有一项未完成就不判定ready。它只是教学门禁，不完成构建、签名、审核或法律合规检查。

```python
artifact = {"version": "1.0.0", "signed": True, "tested": True, "privacy": False}
def ready(item):
    return (isinstance(item.get("version"), str) and bool(item["version"].strip())
            and all(item.get(name) is True for name in ["signed", "tested", "privacy"]))
assert not ready(artifact)
assert not ready({"version": "1.0.0"})
artifact["privacy"] = True
assert ready(artifact)
assert not ready(dict(artifact, privacy="checked"))
print(ready(artifact))
```

实际输出 `True`。初始 privacy 为假时不能就绪；缺少检查字段或把结果写成字符串也不能通过。完成全部布尔检查后才通过。字段值在模型里人工填写，真实流水线应链接签名验证、测试记录与声明复核证据，不能让任何人把布尔值改为真就跳过检查。

不同产物要增加不同条件，例如目标系统安装结果、扩展权限复核与数据库迁移验证。就绪表示满足这张表定义的检查，不能被解释成所有平台或所有法规都已满足。

## 更新与数据迁移怎样恢复

客户端更新从可信渠道取得，验证来源与必要签名，再执行版本策略。安全传输不能单独证明产物由正确发布者制作，校验值也只有来自可信记录时才有意义。更新失败保留当前可用版本，并向用户报告状态。

数据迁移先确认输入版本，按完整事务或平台支持的安全提交机制写入。测试中断与重复运行，防止迁移执行两次破坏数据。升级后的数据库可能不再兼容旧程序，回退必须说明数据版本，而不是简单安装旧包就称为恢复。

服务端接口保持预期兼容，旧客户端仍可能存在。必要迁移与服务更新按顺序发布，并留出失败观察和回退策略。紧急修复同样需要验证实际产物，不能以紧急为由把未检查版本直接标为成功。

## 发布后仍需维护记录

记录错误码、版本和复现条件，避免日志包含私人正文或凭证。区分启动失败、迁移失败、接口错误与更新失败，让下一次修复能对应具体原因。测试环境故障也不能混作用户设备上的真实问题。

维护计划覆盖依赖、系统兼容、权限变化与渠道政策。停止支持某系统时说明最低版本变化和用户恢复路径，不能只更新构建配置。公开文章不包含账户细节、密钥或内部数据，教学案例用合成内容保持可分享。

## 练习：交付一份发布证据

选一个平台建立候选记录，包含实际产物、版本、目标环境、安装与升级结果。制造一次迁移中断和一次更新下载失败，验证原数据与可用版本保留，恢复动作有明确限制。

让另一位测试者从干净环境重放核心路径，并对照权限声明。未提交审核就标记为未提交，处理中就保留处理中。完成记录后才进入对应渠道发布；Python门禁仅验证示例条件，不能替代真实平台与分发验收。

## 资料来源与延伸阅读

- [Upload builds to App Store Connect](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/)
- [Prepare and release an Android app](https://developer.android.com/studio/publish)
- [Publish an extension](https://developer.chrome.com/docs/webstore/publish)
- [Electron security guidance](https://www.electronjs.org/docs/latest/tutorial/security)

资料核验：2026-11-10。教学示例不代表线上实测。

## 相关文章

- [AI 应用上线检查：超时、重试、权限与回滚](https://yishto.com/learn/production/shipping-checklist/)
- [让每次发布都能检查，也能恢复](https://yishto.com/learn/delivery/cicd-monitoring-and-incidents/)