企业官网建设流程全解析

• 教程
• 文档

一个能在你电脑和手机上运行的程序，和真正发布给用户使用的产品，是两回事。无论你用的是 Flutter、React Native、Electron、Qt 还是原生开发，最后都要走过同一条路：确定渠道 → 固定应用身份 → 构建 Release 包 → 签名 → 内测 → 准备商店资料 → 提交审核 → 灰度发布 → 监控与更新。本文以 Datawhale easy-vibe 项目 stage-3 跨平台发布指南 为核心骨架，结合仓库中配套的交互组件与相邻实战教程，完整讲解 Android、iOS、Windows、macOS、Linux 和 Web/PWA 的发布方法，以及中国大陆 Android 商店、小程序和浏览器插件的特殊流程。读完你会得到一套可复用的发布方法论和一份可以直接照做的首次上架清单。

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

1. 先分清四件事：打包、签名、分发、审核

"上架"这个词把四个完全不同的问题混在了一起，遇到发布问题时，先判断卡在哪一步会让排查容易得多。easy-vibe 仓库在 ReleasePipeline.vue 组件中用一张"从代码到商店"的流水线图把四步拆开，每一步回答一个不同的问题：

• 打包把源码和资源编译成用户或商店可以接收的文件；
• 签名用证书或密钥证明发布身份，并让旧用户能够继续升级；
• 分发决定用户通过应用商店、官网、测试渠道还是企业设备管理获得软件；
• 审核是平台对程序、隐私、支付、内容和商店资料的政策与质量检查。

能生成安装包只完成了第一步：一个构建可能打包了但未签名、签名了但未分发、或私下分发但没有经过公开商店审核。没有正式签名的包很难获得用户和系统信任，也不能稳定更新。

2. 用组织身份持有资产

正式产品尽量使用组织控制的账号、邮箱、域名、云服务和支付资料，不要把应用永久绑定在外包人员或某位员工的私人账号里。这些资产要明确负责人，并开启双重验证：

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

3. 尽早固定应用身份，区分版本号和构建号

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

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

com.example.fridgechef

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

用户看到的是版本号，商店识别每次上传的是构建号（Android 的versionCode或 Apple 的 Build）。即使只是修复同一版本的打包错误，再次上传时也要增加构建号。建议从一开始就记录：

Version: 1.0.0 Build: 1 Git tag: v1.0.0 Planned release date: 2026-09-01

4. 准备真正的 Release 环境

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

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

5. 从真实构建准备商店素材

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

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

常见必需项包括应用名称、副标题或简短介绍、完整介绍、图标、真实运行截图、分类、年龄分级、支持邮箱、官网、隐私政策链接和版权信息。截图必须与当前提交的版本一致，不要用设计稿冒充真实功能；同时从每张图中移除手机号、真实聊天记录、访问令牌、客户数据和本地文件路径。

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

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

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

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

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

应用需要登录时，在审核备注中提供专用测试账号、密码和操作步骤。审核账号不能要求短信验证码，也不能依赖已经过期的邀请链接。可以参考仓库文档给出的审核备注模板：

Test account: review@example.com Test password: stored in the review console, do not commit to a public repository Entry: Home -> Login -> Demo project Special notes: demo account has preloaded data, no SMS verification needed

提交前请让一位没有参与开发的人，完全照着审核说明走一遍。

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

8.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。

8.2 提交 Google Play

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

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

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

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

多市场发布时务必保持：

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

在中国境内从事互联网信息服务的 App 主办者需要按规定履行APP 备案手续，备案通常由网络接入服务提供者或分发平台协助提交，不同业务还可能需要相应许可。不要为了统计渠道而临时接入来源不明的 SDK——渠道统计更适合在合规的后端归因或构建流水线中完成。

9. iOS：通过 App Store 发布

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

9.1 创建应用记录

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

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

9.2 归档与 TestFlight

在 Xcode 中选择真实设备构建目标，使用Product → Archive生成归档。先 Validate，再上传到 App Store Connect。上传完成并经过处理后，把构建加入 TestFlight：

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

9.3 提交审核

在版本页面选中构建，补齐截图、描述、隐私申报、年龄分级、出口合规和审核信息。然后先点 Add for Review，再在审核页面点 Submit for Review——只完成前一步并不等于已经送审。审核被拒后，先根据具体条款复现问题：能通过补充说明解决的，就在 App Store Connect 回复；需要改代码时，增加构建号、重新归档并选择新构建，不要只上传同一个包反复碰运气。

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

Windows 有两条常见路线。

10.1 Microsoft Store

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

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

提交 MSIX 到商店时，商店会在认证流程中重新签名；若提交传统 Win32 的 MSI/EXE，安装程序和其中的可执行文件仍需满足相应签名要求。

10.2 官网直接下载

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

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

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

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

11.1 Mac App Store

流程与 iOS 类似：在 App Store Connect 创建 macOS App，配置签名和 App Sandbox，使用 Xcode Archive 上传，补齐商店资料后提交审核。商店版本要遵守沙盒、能力和更新规则，后续更新应由商店提供。

11.2 官网分发

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

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

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

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

• Flathub：准备 Flatpak manifest、AppStream 元数据、图标和截图，在本地完成构建与 lint，然后按 Flathub 流程向对应仓库的new-pr分支提交 Pull Request。审核合并后应用进入独立仓库，后续更新在该仓库维护。
• Snap Store：创建开发者账号，注册唯一的 snap 名称，准备snapcraft.yaml，构建并测试.snap，再上传到测试或 stable 渠道。Snap 支持用 channel 管理 edge、candidate 和 stable。
• 直接发布：AppImage 适合提供单文件下载，.deb和.rpm更贴近发行版的软件包管理。直接发布时仍要提供校验值、依赖说明、架构说明、更新方式和可信下载源。

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

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

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

如果需要"安装到桌面"的体验，再补齐 PWA 的 Manifest、图标和 Service Worker。PWA 也可以进一步提交到部分桌面应用商店，但不要为了上架而套壳——先确保浏览器中的安装和更新体验可靠。easy-vibe 的 PWA 本地应用教程 完整演示了从普通网页到可安装离线应用的闭环，是理解 Web 发布前置条件的最佳配套读物。

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

微信小程序

一般流程是：在微信开发者工具上传代码 → 后台选择版本 → 配置隐私保护指引和业务类目 → 提交审核 → 审核通过后发布。涉及支付、内容、医疗、教育等业务时，还要按当前类目准备资质。体验版和正式版使用不同环境时，特别检查 API 域名、云环境、支付商户号和隐私弹窗，避免审核包仍连接测试服务。

浏览器插件

Chrome Web Store、Microsoft Edge Add-ons 和 Firefox AMO 都有自己的开发者后台。通常需要上传扩展压缩包，填写功能、权限用途、隐私行为、截图与测试说明，再等待审核。权限要遵循"最少够用"：只读取当前站点，就不要申请所有网站；只在用户点击时执行，就不要持续读取浏览历史。

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

不要让 AI 凭印象解释某条审核规则。把审核后台给出的原文、条款编号和当前应用行为一起交给 AI，再要求它给出"复现步骤、可能原因、最小修改、复测方法"。可以使用这个提示词：

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

修改完成后，再问一次：

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

最终仍以平台回复为准。

16. 不要直接全量发布

更稳妥的发布顺序是：

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

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

17. 更新时不能变的东西

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

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

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

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

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

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

19. 在 easy-vibe 中的定位与配套资源

这篇发布指南是 easy-vibe stage-3 高级开发 跨平台实战链路的收官环节：当你沿着 Android 应用教程 打包出正式 APK、或沿着 PWA 本地应用教程 部署出 HTTPS 站点后，本指南负责把"能运行的代码"变成"能被用户信任的产品"。仓库还在中文版目录提供了两个交互式组件用于直观理解本文框架：ReleasePipeline.vue 展示"打包 → 签名 → 分发 → 审核"四步流水线，PublishChannels.vue 汇总了各平台最常见公开渠道、需要准备的文件与其他分发方式，二者是本文第 1、8～13 节内容的可视化浓缩。

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

• 教程
• 文档