如何把开发好的程序发布上架

程序在自己的电脑和手机上能运行，和真正发布给用户，是两回事。

无论使用 Flutter、React Native、Electron、Qt 还是原生开发，最后都要走过下面这段路：

确定渠道 → 固定应用身份 → 构建 Release 包 → 签名 → 内测 → 准备商店资料 → 提交审核 → 灰度发布 → 监控与更新

下面分别介绍 Android、iOS、Windows、macOS、Linux 和 Web/PWA 的发布方式，同时补充国内 Android 商店、小程序和浏览器插件。

规则会变化

商店支持的 SDK、目标系统版本、截图尺寸、账号验证和审核规则会持续更新。这里讲的是稳定的发布方法；真正提交前，请再查看对应后台的最新提示和文末链接的官方文档。

1. 先分清四件事

打包、签名、分发和审核经常被混在一起说成“上架”，其实它们解决的是四个不同问题。

2. 一张表选发布渠道

手机、电脑和网页的发布入口并不相同。点击下面的平台，可以直接查看它最常见的公开渠道、需要准备的文件和其他分发方式。

如果是第一款作品，不必第一天同时上六个平台。先选择用户最集中的一个渠道，把一次完整发布做通，再复用商店资料和自动化流程扩展其他平台。

3. 所有平台共用的发布前检查

3.1 用组织身份持有资产

正式产品尽量使用组织控制的账号、邮箱、域名、云服务和支付资料。不要把应用永久绑定在外包人员或某位员工的私人账号里。

这些资产要明确负责人，并开启双重验证：

• 开发者账号和商店后台；
• 域名、DNS 和官网；
• 签名证书、密钥库及恢复材料；
• 云服务、数据库、对象存储和监控平台；
• 收款、税务与合同资料。

3.2 尽早固定应用身份

Android 的包名、Apple 的 Bundle ID、Windows 的包身份和各商店中的产品记录，都是应用的“身份证”。发布后随意更换，通常会被平台视为一个全新的应用，旧用户也无法正常升级。

可以用反向域名格式统一命名，例如：

com.example.fridgechef

正式发布前确认名称、包名、开发者主体和商标归属，不要继续使用教程里的 com.example.myapplication。

3.3 区分版本号和构建号

用户看到的是版本号，例如 1.2.0；商店识别每次上传的是构建号，例如 Android 的 versionCode 或 Apple 的 Build。即使只是修复同一版本的打包错误，再次上传时也要增加构建号。

建议从一开始就记录：

版本：1.0.0
构建：1
Git 标签：v1.0.0
发布日期：计划中的日期

3.4 准备真正的 Release 环境

发布包不能继续连接本机地址、测试数据库或沙盒支付。至少确认：

• API 使用生产域名和 HTTPS；
• 没有把管理员口令、模型密钥或服务端密钥写进客户端；
• 测试账号、演示数据和调试菜单不会暴露给普通用户；
• Release 包关闭不必要的详细日志；
• 崩溃监控、服务告警和客服入口可用；
• 数据库升级不会清空旧用户的数据。

3.5 准备商店素材

可以先建一个 release-assets 文件夹集中管理：

release-assets/
├── icon/
├── screenshots/
│   ├── android/
│   ├── ios/
│   └── desktop/
├── descriptions/
├── privacy-policy.md
├── support.md
├── review-notes.md
└── licenses.csv

常见必需项包括应用名称、副标题或简短介绍、完整介绍、图标、真实运行截图、分类、年龄分级、支持邮箱、官网、隐私政策链接和版权信息。

截图必须与当前版本一致。不要用设计稿冒充真实功能，也不要在截图中留下手机号、真实聊天记录、访问令牌和客户数据。

3.6 让隐私声明与真实行为一致

先盘点应用和第三方 SDK 实际收集的数据，再填写商店问卷和隐私政策。重点检查：

• 收集什么数据，为什么收集；
• 数据发送给谁、保存多久、如何删除；
• 定位、相册、相机、通讯录和麦克风是否确有必要；
• 分析、广告、崩溃监控和登录 SDK 会收集什么；
• 用户能否注销账号并删除数据；
• 未成年人、健康、金融等敏感场景是否有额外要求。

最常见的问题不是“没有隐私政策”，而是代码、权限弹窗、商店申报和隐私政策四者互相矛盾。

3.7 给审核人员一条走得通的路径

应用需要登录时，在审核备注中提供专用测试账号、密码和操作步骤。如果某个功能只在特定地区、时间、设备或账号下出现，也要写清楚。

审核账号不能要求短信验证码，也不能依赖已经过期的邀请链接。提交前请让一位没有参与开发的人，完全照着审核说明走一遍。

4. Android：Google Play 与中国大陆应用市场

4.1 生成正式包

在 Android Studio 中选择 Build -> Generate Signed Bundle / APK。面向 Google Play 的新应用通常选择 Android App Bundle (.aab)；直接发给设备安装时才使用 APK。

创建签名材料后：

1. 把 keystore、别名和恢复说明保存在团队密码库或受控密钥系统中；
2. 不要把 keystore 和密码提交到 Git；
3. 用 Release 配置构建，并在至少一台真实设备上安装测试；
4. 保存本次构建对应的源码提交、版本号和符号文件。

Google Play 对新应用使用 Play App Signing。上传 .aab 后，Play 会为不同设备生成优化过的 APK。官方流程见上传应用到 Play Console。

4.2 提交 Google Play

1. 注册并完成 Play Console 的身份验证；
2. 创建应用，谨慎填写永久且唯一的包名；
3. 完成商店详情、内容分级、目标受众、广告和数据安全等声明；
4. 上传 .aab，处理目标 API、权限和包体检查；
5. 先发布到内部或封闭测试轨道；
6. 使用商店安装出来的版本复测登录、支付、通知和升级；
7. 创建正式发布，先小范围逐步推出，再根据崩溃和差评扩大比例。

不同类型和注册时间的开发者账号可能有额外测试要求，以 Play Console 创建与设置应用中的当前提示为准。

4.3 提交中国大陆 Android 应用市场

中国大陆没有单一 Android 商店。通常要根据目标手机用户选择华为、小米、OPPO、vivo、荣耀、腾讯应用宝等渠道，并在每个平台分别注册、填写资料和提交审核。

可以建立一份渠道表：

渠道	后台账号	当前包版本	审核状态	商店链接	负责人
华为应用市场	组织账号	1.0.0	待提交	-	张三
小米应用商店	组织账号	1.0.0	审核中	-	李四

在中国境内从事互联网信息服务的 App 主办者需要按规定履行 APP 备案手续。备案通常由网络接入服务提供者或分发平台协助提交；不同业务还可能需要相应许可。先阅读工信部的APP 备案通知与要求，再按云服务商和目标商店的当前流程准备材料。

多市场发布时务必保持：

• 包名一致；
• 更新使用兼容的正式签名；
• 版本号和版本代码只增不减；
• 隐私政策、权限用途和实际代码一致；
• 每个渠道包都能定位到同一份源码和构建记录。

不要为了统计渠道而临时接入来源不明的 SDK。渠道统计更适合在合规的后端归因或构建流水线中完成。

5. iOS：通过 App Store 发布

iPhone 面向普通用户的标准公开渠道是 App Store。完整流程由 Apple Developer、Xcode 和 App Store Connect 三部分组成。

5.1 创建应用记录

1. 使用组织控制的 Apple Account 加入合适的开发者计划；
2. 在 Certificates, Identifiers & Profiles 中确认 App ID 和能力；
3. 在 App Store Connect 创建 App 记录；
4. 保证 App Store Connect 中的 Bundle ID 与 Xcode 完全一致；
5. 配置版本、价格、销售地区和团队角色。

付费 App 或应用内购买还需要在后台完成协议、税务和收款信息。

5.2 归档与 TestFlight

在 Xcode 中选择真实设备构建目标，使用 Product -> Archive 生成归档。先 Validate，再上传到 App Store Connect。

上传完成并经过处理后，把构建加入 TestFlight：

1. 先让内部测试员完成核心流程；
2. 再邀请外部测试员覆盖更多设备和账号；
3. 验证首次安装、覆盖升级、登录、订阅恢复、推送和后台恢复；
4. 确认最终提交的就是测试通过的那个构建。

Apple 的完整后台顺序可参考 App Store Connect 工作流。

5.3 提交审核

在版本页面选中构建，补齐截图、描述、隐私申报、年龄分级、出口合规和审核信息。然后先点 Add for Review，再在审核页面点 Submit for Review；只完成前一步并不等于已经送审。官方步骤见提交 App。

如果应用需要登录，审核备注应包括：

测试账号：review@example.com
测试密码：保存在审核后台，不要写入公开仓库
入口：首页 -> 登录 -> 演示项目
特殊说明：演示账号已预置数据，不需要短信验证

审核被拒后，先根据具体条款复现问题。能通过补充说明解决的，就在 App Store Connect 回复；需要改代码时，增加构建号、重新归档并选择新构建，不要只上传同一个包反复碰运气。

6. Windows：Microsoft Store 或官网安装包

Windows 有两条常见路线。

6.1 Microsoft Store

独立开发者第一次公开发布，优先考虑商店：用户安装路径统一，更新和可信度也更容易管理。

1. 注册 Microsoft Store 开发者账号；
2. 在 Partner Center 预留应用名称；
3. 生成并本地测试 MSIX 包；
4. 创建提交，上传包、截图、介绍、年龄分级和隐私信息；
5. 运行 Windows App Certification Kit 或项目对应的发布检查；
6. 提交认证，通过后设置发布时间和可用市场；
7. 从 Store 安装正式版本并复测自动更新。

提交 MSIX 到商店时，商店会在认证流程中重新签名。若提交传统 Win32 的 MSI/EXE，安装程序和其中的可执行文件仍需满足相应签名要求。当前流程见 Microsoft 的发布第一个 Windows 应用。

6.2 官网直接下载

官网分发适合已有销售网站、企业客户或不适合商店的工具。你需要自己负责：

• 使用受信任的代码签名证书签署 EXE、MSI 或 MSIX；
• 通过 HTTPS 托管安装包，并公布 SHA-256；
• 处理 SmartScreen 信誉和误报；
• 提供静默安装、卸载和自动更新方案；
• 保留旧版本与紧急回滚通道；
• 明确支持的 Windows 版本与 CPU 架构。

不要把未签名的陌生 EXE 直接发到群里作为正式发布方式。它既难以建立用户信任，也无法形成可靠更新链路。

7. macOS：Mac App Store 或签名公证后分发

7.1 Mac App Store

流程与 iOS 类似：在 App Store Connect 创建 macOS App，配置签名和 App Sandbox，使用 Xcode Archive 上传，补齐商店资料后提交审核。

商店版本要遵守沙盒、能力和更新规则。通过 Mac App Store 分发的应用，应由商店提供后续更新。

7.2 官网分发

Electron、Qt 和其他桌面应用也常通过官网提供 DMG 或 PKG。正式流程不是“压缩后上传”这么简单，而是：

1. 使用 Developer ID 对应用及内部组件签名；
2. 检查 hardened runtime、entitlements 和嵌套程序签名；
3. 将成品提交 Apple 公证服务；
4. 等待通过后把公证票据 staple 到交付物；
5. 在一台干净的 Mac 上从官网下载并验证 Gatekeeper；
6. 再接入安全的自动更新机制。

Apple 建议对 Mac App Store 之外分发的软件进行公证，详见使用 Xcode 分发测试版与正式版。

8. Linux：Flathub、Snap Store 与直接软件包

Linux 没有覆盖所有发行版的唯一商店，常见选择是 Flathub 和 Snap Store。

Flathub

准备 Flatpak manifest、AppStream 元数据、图标和截图，在本地完成构建与 lint，然后按 Flathub 流程向 flathub/flathub 的 new-pr 分支提交 Pull Request。审核合并后，应用会进入独立仓库，后续更新在该仓库维护。详见 Flathub Submission。

Snap Store

创建开发者账号，注册唯一的 snap 名称，准备 snapcraft.yaml，构建并测试 .snap，再上传到测试或 stable 渠道。Snap 支持用 channel 管理 edge、candidate 和 stable。详见 Publish a snap。

直接发布

AppImage 适合提供单文件下载，.deb 和 .rpm 更贴近发行版的软件包管理。直接发布时仍要提供校验值、依赖说明、架构说明、更新方式和可信下载源。

9. Web / PWA：部署就是主要发布方式

网站没有统一的“上架按钮”。把生产版本部署到 HTTPS 域名并让用户稳定访问，就是最主要的发布。

上线前检查：

• 正式域名、HTTPS、DNS 和证书续期；
• 环境变量与服务端密钥没有进入前端产物；
• 404、离线页和后端故障有可理解的提示；
• manifest.webmanifest 中名称、图标、启动地址和显示模式正确；
• Service Worker 更新后不会让用户长期停留在旧版本；
• 手机、桌面、触屏和键盘操作都经过测试；
• 配置监控、备份、回滚和状态通知。

如果需要“安装到桌面”的体验，再补齐 PWA 的 Manifest、图标和 Service Worker。PWA 也可以进一步提交到部分桌面应用商店，但不要为了上架而套壳；先确保浏览器中的安装和更新体验可靠。

相关教程：开发 PWA 本地应用

10. 小程序和浏览器插件怎么发布

微信小程序

一般流程是：在微信开发者工具上传代码 → 后台选择版本 → 配置隐私保护指引和业务类目 → 提交审核 → 审核通过后发布。涉及支付、内容、医疗、教育等业务时，还要按当前类目准备资质。

体验版和正式版使用不同环境时，特别检查 API 域名、云环境、支付商户号和隐私弹窗，避免审核包仍连接测试服务。

浏览器插件

Chrome Web Store、Microsoft Edge Add-ons 和 Firefox AMO 都有自己的开发者后台。通常需要上传扩展压缩包，填写功能、权限用途、隐私行为、截图与测试说明，再等待审核。

权限要遵循“最少够用”：只读取当前站点，就不要申请所有网站；只在用户点击时执行，就不要持续读取浏览历史。参考 Chrome Web Store 发布入口和 Microsoft Edge 扩展发布流程。

11. 审核最常见的失败原因

现象	常见原因	提交前怎么发现
一启动就崩溃或白屏	Release 配置、生产接口或架构未测试	从商店测试渠道全新安装
审核人员无法登录	验证码、地区限制、账号过期	用审核说明在另一台设备操作
隐私问题	SDK 行为、权限和声明不一致	做一次数据与权限盘点
功能太少或像未完成 Demo	占位页、死链接、按钮无作用	删除未完成入口或补齐完整链路
支付被拒	数字内容没有使用平台要求的支付方式	开发前阅读目标商店支付规则
权限过度	请求了与核心功能无关的敏感权限	删除权限后复测核心流程
素材侵权	图标、字体、音乐或截图来源不明	保存授权、发票或许可证记录
描述与程序不一致	复用了旧截图和营销文案	以候选发布包重新制作素材

不要让 AI 凭印象解释某条审核规则。把审核后台给出的原文、条款编号和当前应用行为一起交给 AI，再要求它给出“复现步骤、可能原因、最小修改、复测方法”。最终仍以平台回复为准。

可以使用这个提示词：

这是商店的审核反馈：【粘贴原文】。请指出对应规则和需要修改的功能，不要猜测。

修改完成后，再问一次：

请列出重新提交前要复测的操作，以及需要更新的商店资料。

12. 不要直接全量发布

更稳妥的发布顺序是：

1. 开发者本机和真机测试；
2. 团队内部测试；
3. 邀请少量真实用户封闭测试；
4. 提交商店审核；
5. 通过后分阶段或小比例发布；
6. 观察崩溃率、接口错误、登录、支付和客服反馈；
7. 指标稳定后再扩大到全部用户。

真正的发布计划还要写清楚：谁按下发布按钮、谁盯监控、出现什么指标就暂停、如何回滚、用户需要怎样被通知。

13. 更新时不能变的东西

新版本通常必须保持相同的应用身份和兼容签名，并提高构建号。更新前重点检查：

• Android 包名、Apple Bundle ID、Windows 包身份没有变化；
• Android 上传密钥和签名链可用；
• 本地数据库能够从旧结构迁移到新结构；
• 自动更新不会破坏正在编辑的数据；
• 商店隐私申报随新增 SDK 和功能一起更新；
• 后端接口先兼容旧客户端，再发布新客户端；
• 旧版本仍有一段受控的可用或升级窗口。

签名密钥、开发者账号和包身份不是普通构建文件。丢失它们，可能等于失去给现有用户发布更新的能力。

14. 第一次上架的最短行动清单

如果信息太多，先完成下面十步：

• [ ] 选择第一个平台和唯一发布渠道；
• [ ] 用组织账号注册开发者后台；
• [ ] 固定应用名、包名或 Bundle ID；
• [ ] 准备并安全备份签名材料；
• [ ] 构建 Release 包，在干净设备上安装；
• [ ] 准备图标、截图、介绍、支持页和隐私政策；
• [ ] 提供长期有效的审核测试账号；
• [ ] 通过内测渠道安装并走完核心流程；
• [ ] 提交审核，保存每次反馈与修改记录；
• [ ] 小范围发布，确认监控正常后再全量。

上架不是开发结束后的行政手续，而是产品工程的一部分。把身份、签名、隐私、测试、监控和回滚从第一版就设计好，第二次发布会比第一次轻松很多。