鸿蒙应用上架超级清晰教程！！

本文算是上架说明书，AI+开发部分如果本文效果好后面会更新，很多地方要细致去看可以去官网（每个地方我都有附上链接）。

2025年我和团队上架了第一款鸿蒙APP，拿到了创作者激励1万元

最近鸿蒙开发者激励2026开始了，新应用任意自然月有效月活达400 评分高于3 就能直接拿3000，而且单个开发者最高能拿100万

很多独立开发者、OPC还在卷App Store
殊不知对于小开发者 鸿蒙端也是一座“金矿”
新应用任意自然月有效月活达400 评分高于3
就能直接拿3000
而且单个开发者最高能拿100万
还不赶紧干起来？？

但鸿蒙本身对很多开发者就是个从未接触过的东西，上架还有很多高概念要理解，这篇文章带你解决这些问题。

第一次上架 HarmonyOS 应用，最容易犯的错，是一写完代码就去找“提交审核”。

但这会得考虑以下几个问题：

你的包是什么，签名配好了吗？
包名和 AGC 里的一样吗？
隐私政策写好了没，能不能正常打开？
审核人员不用找你要账号，也能看到核心功能吗？

很多应用被打回来，问题不在代码多难，而在材料对不上。

截图写了 A，应用里只有 B。隐私政策说得很干净，应用一启动就申请相册和定位。分类选得像教育产品，里面跑的是内容聚合。包上传了，审核人员连主页都进不去。

这些问题低级吗？低级。常见吗？非常常见。

所以这篇不从“怎么点按钮”讲起，先把包、签名、包名、版本号、隐私声明这些词讲清楚，再按真实上架顺序往下走。

官方入口： 提交 HarmonyOS 应用与鸿蒙 APP 和 在应用市场分发。

开发环境

DevEco Studio：写代码、看预览、跑模拟器、连接真机、配置签名、构建包的主工具。你可以先把它理解成鸿蒙开发的工作台。

HarmonyOS SDK：应用能调用哪些系统能力，和 SDK/API 版本有关。你用什么 SDK 开发，目标设备支持什么版本，都会影响应用能不能跑。

ArkTS：HarmonyOS 应用常见的开发语言。你可以把它理解成 TypeScript 语法体系上的鸿蒙应用开发语言，不要直接把它当普通网页 TypeScript。

ArkUI：写界面和组件的框架。页面长什么样、按钮怎么响应、状态怎么变化，很多都在 ArkUI 里写。

模拟器 / 真机 / 云调试：本地能跑不代表所有设备都能跑。模拟器适合快速看效果，真机适合确认真实体验，云调试适合补你手里没有的设备。

Hvigor / 构建任务：工程最后要通过构建任务打成 HAP、HAR、HSP 或 .app 这类产物。你看到“构建成功”，只是说明产物打出来了，还不等于能上架。

AGC：创建应用、管理服务、上传软件包、配置隐私声明、提交审核和发布的后台。

一个比较好的顺序是：

1. 装 DevEco Studio。
2. 配 HarmonyOS SDK。
3. 新建或导入工程。
4. 跑通模拟器或真机。
5. 看懂工程里的 Module、Ability、配置文件。
6. 构建发布包。
7. 配签名。
8. 上传 AGC。
9. 做测试和上架前体检。
10. 提交审核。

官方开发入口可以看 HarmonyOS 开发入门 和 应用开发概述。

名词解释

ArkTS 和 ArkUI 是什么

如果你以前写过 Web，第一次看鸿蒙工程，很容易把 ArkTS、ArkUI、页面、组件直接套成“前端那套东西”。

可以类比，但别完全等同。

ArkTS 更像你写应用逻辑和界面结构时使用的语言。ArkUI 则是声明式 UI 框架，你用组件、状态和布局把页面搭出来。

一个按钮能不能点，一个列表怎么刷新，一个页面状态怎么变化，通常会落到 ArkTS 和 ArkUI 代码里。

官方概念可以看 ArkTS 概述 和 ArkUI 声明式开发范式。

Stage 模型、Ability 是什么

HarmonyOS 应用不是只有“页面”。

更接近的层级是：

应用 下面有 Module。
Module 里面会声明 Ability。
UIAbility 承载能和用户交互的应用入口。
页面和组件 才是用户真正看到和点击的界面。

你可以先这样理解：

UIAbility 像门。页面像门后面的房间。

审核人员打开应用，首先要能从门进去。如果入口 Ability 配错，或者启动后进不了核心页面，后面的功能写得再多也没用。

还有一种 ExtensionAbility，它更像特定场景下被系统或其他能力调用的扩展能力。新手第一次做普通应用，不需要一开始深挖所有 ExtensionAbility 类型，但要知道它和普通可见页面不是一回事。

官方可以看 Stage 模型开发概述。

Module 是什么

Module 这个词一定要单独讲。

很多新手会把 Module 当成“页面”，或者当成“最终上传的包”。这两个理解都不准。

Module 更像工程里的一个功能单元。

一个应用可以只有一个 Module，也可以拆成多个 Module。比如一个应用里有首页、订单、个人中心、公共组件、网络库、图片资源，你可以把它们按工程需要拆到不同 Module 或库里。

Module 和包的关系大概是这样：

entry Module：通常是应用主入口，普通应用至少会有一个。
feature Module：可以承载某个独立功能。
HAR：更像静态共享库，常用来放公共代码、组件、工具。
HSP：更像运行时共享包，用在需要动态共享能力的场景。
HAP：Module 构建后可能形成的安装包单元。
.app / APP Pack：最后提交或分发时更靠近整体发布态的包。

所以别把它们混在一起。

Module 是工程怎么拆。HAP / HAR / HSP 是构建后出来的产物类型。.app 是更靠近提交发布的整体包。

举个更贴近新手的例子：

你做一个课程 App。

entry 里放启动入口、首页、基础导航。
feature-course 里放课程详情、播放页、课程列表。
feature-profile 里放个人中心、订单、设置。
common 做成 HAR，放网络请求、按钮组件、时间格式化工具。

最后构建时，这些工程单元会影响打出来的包。你上架时不一定直接上传每一个 Module，但 Module 的配置、权限、Ability、资源都会进入最终产物。

官方可以看 Module 概述 和 应用包概述。

AGC 是什么

AGC 是 AppGallery Connect，也就是华为应用发布和管理的后台。

创建项目、创建应用、上传包、配置隐私声明、做云测试、提交审核、分阶段发布、看数据，最后基本都会回到 AGC。

AGC 里有两个词新手很容易混：项目和应用。

项目更像一个资源容器，里面可以放服务、配置和多个应用。应用才是最后上架给用户下载的那个产品。

创建应用时会让你填 APP ID、包名、平台、设备类型、分类、默认语言。这里别顺手乱填。后面签名、服务开通、包体上传、审核信息，都会绕回这些字段。

官方对 AGC 的说明可以看 AppGallery Connect 概览。

包是什么

“包”到底是什么？

你可以先别想技术概念，直接把它理解成：

你把代码写完以后，系统帮你装进一个盒子里。这个盒子，就是包。

这个盒子最后要拿去干三件事：

拿去手机/模拟器上安装。
拿去测试。
拿去上传到 AGC，准备上架或提交审核。

在 HarmonyOS 里，最容易遇到的是这几个“盒子”。

HAP = 应用里的某个模块打出来的包。

它里面通常会放这个模块的代码、页面、图片、配置等东西。

.app：一个大盒子

.app，也叫 APP Pack。

它更像是最终提交用的“大盒子”。

如果 HAP 是一个个小盒子，那 .app 就像把这些小盒子统一装进一个大箱子里。

你最后上架、比赛提交、发给别人审核时，经常要看的就是这个最终的大包。

所以你可以先这样记：

HAP = 单个模块包。
.app = 最终提交包。

举个例子：

你做了一个外卖 App。

首页模块打出来一个 HAP。
订单模块打出来一个 HAP。
我的页面模块打出来一个 HAP。

最后这些模块被装到一个 .app 里。

那 .app 就是你最终拿去上传 AGC 的东西。

HAR = 被别人引用的公共代码包，更像工具箱。

HSP：共享零件包

HSP 比 HAR 更像“运行时共享的零件包”。

它也不是新手第一次上架最需要关心的主角。你可以先简单理解成：

HSP = 多个模块运行时可以共用的一部分能力。

新手不需要一开始就深挖 HAR 和 HSP。你只要知道：
它们通常不是你最终直接上传的那个包，但它们会影响最后打出来的 HAP 或 .app。

第一次上架，最重要的不是背概念，而是检查这几件事：

第一，看你打出来的是不是发布包。

第二，看包有没有签名。

第三，看包名对不对。

第四，看模块有没有漏。

第五，看目标设备能不能安装。

第六，看核心功能能不能跑。

所以最简单的理解是：

HAP 是模块小包，.app 是最终大包，HAR 是公共工具箱，HSP 是共享零件包。

打包这件事，本质上就是：把你写好的代码、资源、配置，装成一个平台能识别、设备能安装、审核能通过的文件。

包名是什么

包名就是应用在系统和平台里的身份标识。

用户看到的是应用名，系统和平台识别的是包名。你在 AGC 创建应用时填的包名，必须和工程里的包名对上。很多服务开通、签名指纹、应用配置、包体上传，都靠它把“这个包”和“这个后台应用”认成同一个东西。

有些问题一开始看起来像服务调用失败、配置不生效、审核包不匹配，最后一查，只是包名或者 APP ID 没对上。

签名是什么

签名可以先理解成给应用包盖章。

这个章要说明两件事：包是谁发布的，包在传输和安装前有没有被改过。

HarmonyOS 应用开发和上架会遇到数字证书、Profile、签名信息、签名证书指纹这些词。名字看着吓人，其实可以先拆成三层：

数字证书：证明“谁来签这个包”。

Profile：说明这个包在什么场景下可以运行或发布，里面会关联应用、设备或发布相关信息。

签名证书指纹：把证书信息登记到平台侧，让 AGC 或相关开放能力知道“这个签名确实属于这个应用”。

华为的一些 Codelab 会把准备工作列成：在 AGC 创建应用，生成数字证书和 Profile，配置签名信息，生成签名证书指纹，再在 AGC 配置指纹。比如 地图服务 HarmonyOS Codelab 就写到了这些步骤。

这里最容易误判：本地能跑，就以为签名没问题；调试能跑，就以为发布也没问题。

调试签名和发布上架不是一回事。上架前要确认你上传的是正式发布需要的签名包，不是随手跑通的调试包。

配置文件是什么

鸿蒙工程里会有一堆 .json5 文件

这些文件会直接影响你最后能不能构建、能不能安装、能不能申请权限、能不能和 AGC 对上。

常见先看这几个：

app.json5：应用级配置。应用名、图标、版本、包名等全局信息会和它有关。

module.json5：Module 级配置。Module 类型、Ability、页面入口、权限、metadata 等信息会在这里出现。

oh-package.json5：依赖配置。你用了哪些三方库、内部库，通常要从这里看。

build-profile.json5：构建配置。构建目标、签名、产物相关配置会和它有关。

这几个文件和上架的关系很直接：

• 包名对不上，AGC 可能认不出你的包。
• 版本号乱了，更新和审核会混。
• Ability 配错，审核人员可能进不了核心功能。
• 权限声明缺了，运行时可能申请不了。
• 权限声明写了但隐私政策没写，审核可能打回来。
• 依赖或共享包配置乱了，构建产物可能不是你以为的那个。

官方可以看 应用配置文件 和 Module 配置文件。

版本号是什么

版本号不是给自己看的备注。

它决定平台和用户怎么识别这次更新。你上传新包时，版本号、版本名称、更新说明都要讲得通。一个很常见的混乱是：包明明改了，版本号没改；或者版本说明写了一堆，包里没看到对应变化。

第一次上架不用搞复杂，确认当前包就是准备公开的第一版，版本信息和发布说明能对上就行。

隐私声明是什么

隐私声明不是“放一个隐私政策链接”就结束了。

它要回答：你收集什么、为什么收集、怎么用、有没有第三方组件、用户怎么联系你。

AGC 里填的内容、应用内弹窗、隐私政策正文、应用实际行为要一致。这里对不上，特别容易被打回来。

真正上架顺序

0. 先确认本地工程能正常交付

在账号和 AGC 之前，先别急。

先确认你的本地工程不是“勉强能跑一下”的状态。

这一轮我会看：

• DevEco Studio 和 HarmonyOS SDK 是否装好。
• 模拟器或真机能不能跑起来。
• entry Module 是否能正常启动。
• UIAbility 能不能进入核心页面。
• app.json5 里的应用信息和版本信息是否合理。
• module.json5 里的 Ability、权限、metadata 是否符合当前功能。
• 依赖和公共库有没有缺失。
• debug 包和 release 包有没有分清。
• 构建产物到底是 HAP、HAR、HSP 还是 .app。

这一轮不是为了“写得优雅”，是为了确认你手里的工程能变成一个可提交的产品。

1. 先把开发者账号和主体定下来

上架前，先注册华为开发者账号，并完成实名认证。

如果只是个人练手，个人账号可以。但如果是公司业务，主体信息要早点确认。后面资质、商户服务、数字商品、付费协议都可能跟主体挂钩。

这一步先查四件事：

• 账号是否实名。
• 团队成员和权限是否配置好。
• 后续资质主体能不能和开发者主体对上。
• 如果要接支付、数字商品、游戏服务，相关协议是不是要提前签。

主体一旦乱了，后面就不是改个标题那么简单。资质、协议、收款、业务归属，都可能跟着返工。

2. 在 AGC 里创建项目和应用

进 AGC 后，先建项目，再建应用。别把这一步当成“填个表”。

建应用时，最容易影响后续的是这些字段：

• 应用名称。
• 包名。
• 平台。
• 设备类型。
• 应用分类。
• 默认语言。

应用名称给用户看，包名给系统和平台识别。平台和设备类型决定你走哪条发布路径。分类会影响审核要看哪些材料、要不要补资质。

别用“先随便填，后面再改”的心态。

有些字段后面能改，有些字段改起来麻烦，有些字段会牵出一堆配置。第一次上架，宁愿在这里多花十分钟。

3. 在 DevEco Studio 里构建发布包

开发完成后，回到 DevEco Studio 构建发布包。这里开始，事情就从“代码能跑”变成“发布物能不能交出去”。

你要搞清楚自己当前生成的是 HAP 还是 .app，调试包还是发布包，签名有没有配好。

我建议按这个顺序来：

1. 先本地运行，确认功能能用。
2. 再构建准备上传的发布包。
3. 检查签名配置。
4. 检查包名、版本号、设备类型。
5. 尽量在目标设备或云调试环境装一遍。

不要只看“构建成功”四个字。

构建成功只能说明包打出来了，不代表它适合上架。能不能安装、能不能启动、核心流程能不能走完，才是上架前真正要确认的事。

4. 配好签名，不要拿调试状态碰审核

签名这一步，新手很容易想跳过去，因为它不像界面 bug 那样一眼能看见。

不要跳。

你要确认数字证书、Profile、签名配置、签名证书指纹这些信息能对上。尤其是接入华为账号、地图、推送、支付等开放能力时，签名指纹和 AGC 配置经常会影响服务能不能正常跑。

这里直接照着查：

• 当前包使用的是不是发布需要的签名。
• Profile 是否对应当前应用和发布场景。
• 签名证书指纹是否已经在 AGC 或相关服务里配置。
• AGC 里的应用包名和工程包名是否一致。

如果遇到“本地运行可以，上传后不对”“服务开关开了但调用失败”这类问题，先别急着怀疑接口。包名、APP ID、签名指纹，先查一遍。

5. 上传软件包，让 AGC 做基础检测

包准备好以后，上传到 AGC。上传之后，它就不再只是你电脑里的一个文件，而是审核要看的对象。

AGC 会对上传的软件包做基础合法检测。检测通过的包，后面发布版本才能选。

这里常见两个小坑：把临时测试包传上去；上传完不看检测结果。

你本地还有另一个“更好的版本”，对审核没意义。审核只看你交上去的东西。

上传后顺手确认：

• 检测是否通过。
• 包名是否匹配。
• 版本号是否符合预期。
• 设备类型是否正确。
• 这个包是不是最新的发布包。

官方应用市场分发文档写得很直白：需要先上传应用或元服务软件包，AGC 会做基础合法检测，检测通过的包才能在发布版本时被选取。

6. 填应用信息，别把未来功能写进去

应用信息包括名称、简介、分类、标签、图标、截图、视频、语言、分发地区。

审核看的不是文案漂不漂亮，主要看材料和应用能不能对上。

比较稳妥的写法是：

• 简介只写已经实现的功能。
• 截图来自真实应用页面。
• 分类按主要功能选。
• 标签不乱蹭。
• 图标、应用名、隐私政策里的名称保持一致。
• 分发地区和语言材料能对上。

如果应用需要登录后才能看到核心功能，要准备审核账号或审核说明。不要让审核人员停在登录页。

如果有特殊使用方式，也写清楚。比如需要先创建数据、需要接入某个硬件、需要特定测试环境。你不写，审核人员大概率会按普通用户路径去点。

官方应用市场接入流程可以看 应用市场接入。

7. 单独做一轮隐私核对

隐私材料建议单独拿出来查，不要夹在应用信息里顺手填。

不要边填边猜。

先列应用实际行为：

• 是否登录。
• 是否收集手机号、昵称、头像。
• 是否读取设备信息。
• 是否申请定位。
• 是否访问相册、相机、麦克风。
• 是否有推送。
• 是否有支付。
• 是否接入第三方 SDK。
• 是否有用户画像、数据分析、广告、客服、风控。

再对照三份材料：

• 应用内授权提示。
• 隐私政策正文。
• AGC 里的隐私声明或隐私标签。

三边要说同一件事。

最容易被打回来的情况是：应用里申请了权限，隐私政策没说；隐私政策套了一个泛泛模板，真实行为比模板复杂；第三方组件收集数据，但声明里没披露。

官方隐私声明入口在 在应用市场分发。

提交前清单

这张表不高级，但能省很多返工。提交前照着扫一遍。

• 开发者账号已经实名认证。
• AGC 项目和应用建对了。
• 包名和 AGC 应用一致。
• 上传的是正式发布包。
• 包已经按发布要求签名。
• Profile、证书、签名指纹能对上。
• 版本号和发布说明没乱。
• 应用名称、简介、截图、分类和真实功能一致。
• 审核人员能进入核心功能。
• 隐私政策链接能打开。
• 权限申请有业务理由。
• 隐私声明、隐私政策、应用内行为一致。
• 第三方组件的数据收集已经披露。
• 需要资质的分类已经补材料。
• 做过 AppAnalyzer、上架前体检或云测试。
• 没有明显崩溃、黑屏、卡顿、空页面、不可点击按钮。
• 提交前重新检查产品包信息、分发信息和基础信息。

元服务、游戏、PC、海外分发的差异

元服务也走 AGC 分发，但有自己的发布入口、隐私声明和资质要求。普通应用材料不能原样复制过去。

游戏要额外注意游戏服务、版署/实名认证、防沉迷、付费、联运等要求。普通应用上架流程只能当底稿，不能直接套。

PC 应用在华为应用分发里有“发布 PC 应用”入口。包体、设备适配、截图素材、交互方式和审核关注点都可能不同。

海外分发会多出国家或地区选择、本地化语言、隐私合规、素材翻译、账号认证、短信、支付等问题。可以先看华为的 应用出海方案。具体国家和地区的法律要求，要单独确认。

结尾

鸿蒙应用上架，最怕把“开发完成”当成“发布完成”。

代码写完，只是你手里有了应用。能不能上架，还要看包、签名、说明、隐私、资质、测试结果能不能对上。

审核看的东西很朴素：用户下载安装到的这个应用，和你提交上来的说明、权限、资质、质量表现，是不是同一个东西。

能对上，流程会顺很多。对不上，再小的问题也会变成返工。

祝大家 build 顺利！！