零基础鸿蒙开发到上架：ArkTS与ArkUI实战全流程

本文梳理从零基础到App上架的鸿蒙开发全流程，涵盖ArkTS与ArkUI技术栈、四阶段学习路线、DevEco Studio环境搭建、记账App实战、签名提审与性能优化，帮你避开常见坑点，完成首个完整项目。

这期内容答应大家很久了。后台一直有朋友在催问：鸿蒙HarmonyOS到底值不值得学、从零基础到自己的App上线要经历哪些环节。这次我干脆把自己完整走过的路径整理出来，当作一份实在的福利，送给准备入坑的朋友。老实说，鸿蒙开发这几年的变化非常大，HarmonyOS 6已经是完全自研底座的纯血架构，早年间那些“套壳安卓”的认知早就过时了。这篇文章就顺着“零基础到上线”这条主线，把技术栈梳理、环境搭建、ArkTS语言与ArkUI框架、完整实战开发、签名上架、问题排查这几大块一次讲透。不管你是完全没写过代码的新手，还是从安卓、前端转过来的开发者，按这条路线走，能少走我踩过的绝大多数弯路。

1. 先把路线图捋清楚：从零到上线到底要学什么

1.1 鸿蒙开发的技术栈到底有哪几块

很多人听到“鸿蒙开发”，第一反应是“跟安卓是不是差不多”。这个想法在HarmonyOS 6时代已经不适用了。新一代系统底层用的是自研内核，不再兼容安卓应用，也没有了历史包袱。对开发者来说，好处是官方把开发范式、工具链、发布渠道全部统一了，你只需要吃透一套技术栈，就能开发手机、平板、折叠屏、车机等多设备应用。

具体来说，这套技术栈可以拆成四块：

ArkTS：开发语言。在TypeScript基础上做静态类型强化，并加入装饰器等能力。写过现代前端的人上手很快，但类型约束更严格。

ArkUI：声明式UI框架。用组件树加状态驱动的方式来描述界面，而不是一句句命令去操作界面。

系统能力Kit：官方封装的系统API集合，网络、存储、定位、多媒体等能力按Kit分类提供。

构建发布工具链：包括DevEco Studio、签名工具、应用市场后台。

前两块决定了你能不能写出一个能跑的App，第三块决定了App的功能上限，第四块决定你能不能把App真正送出去。这四个维度在后面的章节里都会逐一展开讲。

1.2 零基础四阶段学习路线

零基础学鸿蒙，最忌讳的事情就是抱着官方文档从头啃到尾。文档是很全，但也真的很劝退，翻两章就犯困。我实践下来最有效的路线是分四步走，每一步都有明确的产出物，学起来有正反馈，不像漫无目的地刷文档那样越看越没底。

第一阶段：过ArkTS语法。目标不是精通，而是能读懂官方示例、能写业务逻辑。变量、函数、类、数组对象、异步编程、装饰器这六个点必须掌握。如果每天投入两小时，一周左右就能过完，别恋战，语言细节边做边补。

第二阶段：掌握ArkUI高频组件和布局。Text、Button、TextInput、Column、Row、List、Scroll、Tabs、Image这些组件过一遍，再配合尺寸、间距、圆角、背景等通用属性的用法。这一阶段的目标是能拼出一个静态且美观的页面，大约需要两周。

第三阶段：打通数据与交互。页面路由跳转、组件间通信、网络请求、本地存储、权限申请，这些是一个功能型App的骨架。学完这一阶段，就可以开始动手做自己的小项目了，做到这里你已经不是“零基础”了。

第四阶段：完整走一遍发布流程。签名证书、Profile、打包、提审、上架，每一步都自己操作一遍。很多人把这一步拖到产品做完才开始研究，结果一到提审就卡壳。我的建议是学习中期就提前走一遍，后面真正上架时才不会手忙脚乱。

1.3 开发前的准备清单与时间预期

硬件和账号这些事看起来琐碎，但缺一样就能卡你好几天。比如内存不够导致模拟器起不来、开发者账号没认证导致无法申请证书，这些都是我身边朋友真实卡过的地方。为了避免你重蹈覆辙，我把当时的准备清单整理成了一张表：

准备项 | 具体要求 | 我的建议 |

开发电脑 | 内存16GB以上、固态硬盘 | IDE和模拟器同时开非常吃资源 |

开发工具 | DevEco Studio官方版本 | 别用来历不明的整合包或破解包 |

调试环境 | 模拟器或真机至少一种 | 新手先用模拟器，真机留到后期验证 |

开发者账号 | 应用市场开发者账号 | 需要实名认证，提前注册备用 |

SDK与镜像 | 随IDE安装向导自动配置 | 保持版本匹配，不要手动混装 |

时间预期方面，如果每天投入两到三个小时，一个能上架的简单工具类App，两个月是比较现实的周期。其中环境搭建和声明式UI思维转换是最容易劝退的两道坎，熬过去之后的路会顺畅很多。

2. 环境搭建：DevEco Studio从安装到跑通第一个工程

2.1 安装配置中的几个关键选择

DevEco Studio是目前鸿蒙开发的官方IDE，界面和操作逻辑都基于主流现代编辑器定制，用过其他开发工具的人基本可以零门槛上手。安装过程本身不复杂，但我用下来有三个地方想重点提醒，这三个地方做对了能省掉后面一大半的折腾。

第一，SDK版本跟随向导走。安装向导一般会帮你把对应版本的SDK、工具链、模拟器镜像一起配好，这里不要自作主张改默认路径或混装别的版本。SDK和IDE版本不匹配时，编译会冒出一堆莫名其妙的报错，比如某个API找不到、构建工具版本冲突之类，查起来非常痛苦。

第二，内存配置要提前调。IDE默认配置偏保守，创建大工程或打HAP包时容易卡顿甚至构建失败。项目配置文件里可以把构建进程的内存上限调高，16GB内存的机器建议分到4GB以上。这个操作一次到位，后面能省很多等待时间。

第三，命令行工具别漏装。很多人只装了IDE图形界面，到后期想写脚本做自动化构建、批量打包，才发现命令行工具没装。安装时顺手勾上，后面写CI脚本或者本地自动化流程时，就知道多重要了。

这些都不是技术难题，但属于典型的“配置一小时、排查一小时”环节。不少新手在这里被劝退；其实只要按照官方安装向导一步步来、少自作主张，基本不会有问题。

2.2 工程结构一次看明白

第一次创建一个空工程，IDE里会出现一堆目录和文件，很多人当场就懵。其实鸿蒙工程结构是清晰的三层：工程（Project）、模块（Module）、页面（Page）。

工程是顶层容器，用来管理一个应用的所有模块。模块对应一个可以独立构建安装的应用或服务包，比如你做一个应用，可能同时包含主应用模块和桌面卡片模块，它们共享工程配置，但各自打出独立的安装包。页面就是模块里的具体界面，一个模块可以有很多页面。

平时开发最常接触的目录和文件是这几个：

entry：默认主模块目录，代码基本都在里面。

entry/src/main/ets：ArkTS源码目录，页面、组件、工具函数都放这里。

entry/src/main/resources：资源目录，图片、字符串、颜色等。

entry/src/main/module.json5：模块配置文件，声明页面列表、权限、图标等。

AppScope/app.json5：应用级配置，应用名称、应用图标等。

我给新手的建议是，前两周花点时间理解目录和文件，比急着写代码更重要。很多诡异报错，比如运行时页面白屏，根本原因就是module.json5里漏注册了页面。配置文件长这样：

{
  "module": {
    "name": "entry",
    "type": "entry",
    "pages": "$profile:main_pages",
    "abilities": [
      {
        "name": "EntryAbility",
        "srcEntry": "./ets/entryability/EntryAbility.ets",
        "description": "$string:EntryAbility_desc",
        "icon": "$media:layered_image",
        "label": "$string:EntryAbility_label",
        "startWindowIcon": "$media:startIcon",
        "startWindowBackground": "$color:start_window_background",
        "exported": true
      }
    ]
  }
}

页面列表里维护着所有页面路径，新增一个页面却忘记注册，编译期可能不报错，运行时就白屏给你看，这类问题靠肉眼很难定位。所以养成“新建页面立刻注册”的习惯，能帮你躲开一大类隐性bug。

2.3 模拟器和真机怎么选

调试环境的取舍，我的经验是新手阶段无脑用模拟器。原因很实在：启动快、不占真机、随便折腾系统设置都不用怕。DevEco Studio内置的模拟器支持常见手机尺寸和折叠屏形态，开发阶段验证布局、验证交互流程完全够用。

真机调试更适合这些场景：涉及传感器或硬件能力、需要验证真实性能、要测多设备适配、模拟器复现不了的bug。真机调试前要打开开发者模式，再通过IDE完成设备认证，整个过程十来分钟，官方帮助文档写得很详细，照着走就行。

调试工具方面，最常用的是Log窗口、HiLog日志和断点调试。我的工作习惯是在关键逻辑里铺日志，配合断点一起用：断点看变量和调用栈，日志看时序和埋点，两者互补着用效率最高。

鸿蒙的日志体系把业务日志、系统日志、崩溃日志分得很清楚。遇到白屏或崩溃，优先去崩溃日志里找堆栈，绝大多数问题能直接落到具体文件和行号，不用猜。这个习惯会让你在定位问题时比别人快好几倍。

3. 核心开发语言与UI框架：ArkTS和ArkUI的实战理解

3.1 为什么是ArkTS，它和JS/TS有什么区别

ArkTS是鸿蒙应用的主力开发语言，基础语法和TypeScript高度一致。但它在TypeScript的基础上做了两件事：一是收紧动态特性，比如不允许用any绕过类型检查，对象字面量必须明确类型；二是引入装饰器体系，让声明式UI和状态管理有了语言层面的支撑。整体风格更接近强类型语言，很多低级错误在编译期就被拦下来了。

如果你以前写过前端，ArkTS几乎是零成本上手。变量声明、函数、箭头函数、解构、数组方法这些全是熟面孔。但有几个习惯要改：不要随手写any，多用interface定义数据结构；异步逻辑优先用async/await而不是回调嵌套；组件状态变量必须用装饰器标记，否则改了UI不动。

我建议零基础读者不要去单独啃一套完整的TypeScript教程，直接把ArkTS官方语言基础过一遍，边写边查就够了。语言这种东西，靠项目喂出来的速度远快于靠书本啃出来的速度，尤其是鸿蒙这种演进速度快的生态，跟着项目学才能始终保持信息不过时。

3.2 声明式UI：从“一步步操作”到“描述长什么样”

初学ArkUI时最大的心智门槛，是必须完成一次思维转换。传统命令式UI的写法是“拿到界面元素，然后告诉它怎么改”；声明式UI的写法是“直接描述界面结构，数据变了框架帮我自动更新”。这个差别乍看不大，实际体验却完全不同。

看一段最简单的代码：

@Entry
@Component
struct Index {
  @State message: string = 'Hello HarmonyOS'

  build() {
    Column({ space: 12 }) {
      Text(this.message)
        .fontSize(24)
        .fontWeight(FontWeight.Bold)

      Button('更新文字')
        .onClick(() => {
          this.message = '你好，鸿蒙'
        })
    }
    .width('100%')
    .padding(24)
  }
}

这段代码做的事很直观：页面有一个文本和一个按钮，点击按钮后文本内容改变。关键在于，你不需要手动调用“把Text内容改成xxx”，你只改了数据this.message，UI框架检测到数据变化，自动去重新渲染相关组件。这就是状态驱动UI的核心机制，也是理解ArkUI一切高级特性的地基。

写ArkUI页面时，脑子里想的是“这个界面由哪些组件、什么布局结构组成”，而不是“我该怎么一步步把它画出来”。这个弯一旦转过来，看官方示例、写业务页面都会顺畅很多。如果一开始写得很别扭，别怀疑自己，这是每个人都要经历的转化期，通常两周左右就能适应。

3.3 状态管理：从@State到组件通信

@State是最基础的状态装饰器，用来声明一个“变化会引起UI更新”的组件内部变量。单页面里够用，但真实App几乎不可能只有一个组件，多组件之间的数据共享就得靠更多机制了。

我日常开发中常用的几个：

@State：组件内部状态，变化时自动刷新当前组件。

@Prop：父传子的单向数据，子组件里只读。

@Link：父子双向绑定，子组件修改会同步回父组件。

@Provide/@Consume：跨层级组件通信，适合祖先和后代共享数据。

@Observed/@ObjectLink：监听嵌套对象或数组内部字段变化。

选择原则一句话：作用域能局部就别全局，通信层级浅用@Prop/@Link，层级深用@Provide/@Consume，跨页面共享再考虑全局状态管理方案。新手最常见的坑是一上来就全局化，把一堆状态堆到一起，改一个牵动一片，后期维护成本直接爆炸。记住，状态作用域越小，代码可控性越高，这也是所有声明式UI框架通用的铁律。

4. 完整实战：从创建工程到功能跑通

4.1 需求拆解与页面规划

理论说了一堆，下面拿一个具体例子过一遍全流程。假设我们要做一个“日常记账”App：能记录一笔收入或支出，能看到账单列表，能修改和删除记录。就这三个需求，麻雀虽小五脏俱全，非常适合当第一个完整项目。

动手写代码之前，先做两件事。第一件，拆页面。我的信息架构很简单：首页是账单列表，一个新增/编辑页，一个详情页。三个页面，三种职责，互不重叠。第二件，拆组件和数据流。列表页用List组件加自定义列表项；表单页用TextInput和选择控件；数据存在本地，用Preferences做键值存储。页面打开时加载列表，新增和删除后刷新列表。

这个规划过程看起来琐碎，但它是整个项目里最值得花时间的环节。我见过太多人拿到需求就开写，写着写着发现页面结构不合理、数据流说不通，返工成本远大于前期十分钟的规划。尤其是第一次做项目，把页面和数据的边界想清楚，后面的编码会非常顺畅。

4.2 核心页面实现：列表页和表单页

首页账单列表是信息型页面的典型场景。用List组件配合ForEach渲染数据，每条记录是一个自定义子组件：

@Component
struct RecordItem {
  @Prop item: RecordModel

  build() {
    Row() {
      Column() {
        Text(this.item.title)
          .fontSize(16)
        Text(this.item.date)
          .fontSize(12)
          .fontColor('#999')
      }
      .alignItems(HorizontalAlign.Start)

      Blank()

      Text(`${this.item.amount > 0 ? '+' : '-'}${Math.abs(this.item.amount)}`)
        .fontColor(this.item.amount > 0 ? '#e84026' : '#00b96b')
    }
    .padding(16)
    .width('100%')
  }
}

这里用@Prop接收父组件传过来的一条记录，只做展示，不改数据，父子职责很清楚。金额颜色用正负区分，收入和支出一眼就能分辨。RecordModel是一个interface定义的数据结构，里面包含标题、日期、金额、类型等字段，直接用类型约束数据，比到处传对象字面量安全得多。

新增编辑页就是典型表单页：TextInput负责输入标题和金额，选择控件区分收入支出，点保存就把数据写进本地存储，再返回首页刷新。写保存逻辑时要注意校验，金额不能为空、必须能转成合法数字，校验不通过就给用户一个轻提示，避免脏数据入库。这是我反复强调的一点：数据校验必须在入口处把关，后面所有逻辑才能放心地假设数据是干净的。

页面跳转用路由方法，参数通过params传递，比如从列表点一条记录跳到详情页，传一个id过去，详情页自己查数据。功能规模不大时，这是最直接、最不容易出问题的传参方式，没必要为了“优雅”引入复杂的状态管理框架。

4.3 数据获取与本地存储

记账App没有服务端，数据全放本地。本地轻量存储我推荐Preferences，适合存配置和结构化的小数据。用法很简洁：

import { preferences } from '@kit.ArkData';

const store = await preferences.getPreferences(context, 'my_store');
await store.put('record_list', JSON.stringify(records));
await store.flush();

getPreferences获取实例，put写入，flush把内存数据同步到磁盘。这里提醒一个真坑：Preferences的写入是异步的，如果连续put几次然后立刻杀进程，后几次写入可能还没落盘就丢了。我的习惯是每次修改数据都主动flush，虽然多花一点性能，但数据安全优先，开发阶段一定要养成这个习惯。

等App的数据量变大、查询逻辑变复杂，就该考虑关系型数据库了。鸿蒙的数据库API支持标准SQL，用法和常规关系库很像。不过选型原则要记住：能用轻量方案就别上重型方案，不要给一个只需要存一百条记录的工具类App引入数据库，纯属给自己添麻烦。技术选型永远服务于真实需求，而不是反过来。

4.4 调试定位问题的三板斧

没有bug的开发不叫开发。我把平时定位问题的方法总结成三板斧，基本能覆盖九成场景。这套方法不限于鸿蒙，但配合鸿蒙的分级日志体系，用起来格外顺手。

第一板斧，看日志。页面不刷新、数据对不上，先在关键节点打日志。对比理想输出和实际输出的差异，问题点通常立刻浮出来。重点看有没有报错级别的日志，是不是出现在你正在操作的路径上。很多人遇到bug第一反应是改代码，我的第一反应永远是加日志看现场。

第二板斧，断点调试。走到断点说明流程执行到了，变量值对不对一目了然。特别适合排查异步回调里“以为执行了其实没执行”这类隐蔽问题。断点配合条件判断一起用，只在特定值出现时才停下，比手动找快得多。

第三板斧，最小复现集。遇到复杂的诡异bug，先把代码砍掉一半，留一个能稳定复现问题的最小工程，再一行行把代码加回去，定位到引发问题的那一行。这个方法在后台开发、前端开发里同样通用，比盯着完整代码瞎猜高效得多。记住：能稳定复现的bug都是好bug，怕的是那种时有时无的，最小复现集也是让偶发问题变稳定的利器。

5. 上架发布：签名、审核与上线后的维护

5.1 签名证书与Profile的申请流程

上架的第一步不是点“打包”，而是先搞定签名。应用市场要求每个上架包都有合法数字签名，用来证明应用身份和来源，防止被伪造和篡改。整个流程分三步，每一步都有明确的校验逻辑。

第一步，在DevEco Studio里通过证书管理工具生成密钥对和证书请求文件。这里最要紧的是保管私钥，私钥一旦泄露，别人就能冒充你的应用签名，后果相当严重。我的习惯是把私钥单独加密备份，不放进代码仓库，也尽量不通过聊天工具传输。

第二步，登录应用市场开发者平台创建应用，把证书请求文件提交上去，换取对应的应用证书和Profile。这个环节大量报错都源于信息不一致：包名、应用名、签名指纹，任何一项跟工程实际配置对不上，后面校验直接失败。提交之前先逐项核对，能省掉反复的往返。

第三步，在工程构建配置里导入证书和Profile。DevEco Studio的构建配置有签名设置入口，选对文件后构建会自动签名。我第一次打包时漏配了Profile，本地跑得好好的，装到真机上就提示安装失败，排查了老半天才意识到是签名环节的问题。

所以我的建议是，学习阶段就申请一套调试证书，把流程完整走一遍；正式应用要上架时，再申请发布证书，整个流程你已经轻车熟路了。签名这套东西技术上不难，难的是细心，信息一致性的检查做得越细，后面越顺利。

5.2 提审上架的流程与材料清单

签名搞定，打包生成HAP包，接下来就是应用市场后台的提审流程。这一步经常被低估，技术都做完了，人也最容易在材料上翻车。毕竟技术问题你可以调试、可以搜索，材料问题只能对照要求一项项改，没有任何捷径。

材料清单大致是这些：应用名称和图标、简介、功能截图、隐私政策链接、权限说明、测试账号（如果涉及登录）。每一项都有具体格式要求，比如截图尺寸和数量、文案规范、权限描述必须跟实际调用一致。我在提审时遇到的打回原因，最常见就是两类：权限申请理由写得不够充分，隐私政策没有覆盖全部数据采集行为。这两块提前做扎实，能省下至少一轮审核时间。

提交后的审核周期通常不算长，等结果的过程中不用焦虑。被打回也不是坏事，后台给出的原因说明就是明确的修改清单，改完重新提交，一般就顺利过了。我第一次提审被打回时还挺沮丧，后来发现每次打回都是帮我把产品做得更规范，心态就平和了。

5.3 上线后的版本迭代与数据观察

应用上线不是终点，是真正运营的开始。第一个版本上线后，我盯着三件事，这三件事决定了你的App能不能越做越好。

第一件事，盯崩溃数据和应用市场反馈。崩溃日志反映线上问题，优先处理影响范围大的崩溃。用户评价里的体验问题整理成需求池，按优先级排进迭代。很多开发者只看新增用户数，从不看崩溃率，这是本末倒置，体验崩了，用户全跑了，拉新就毫无意义。

第二件事，建立稳定的版本节奏。小步快跑比憋大招稳妥。每周一个小版本修问题，每两周到一个月一个大版本上功能，用户的等待成本低，出问题的风险面也小。长期不更新会让用户觉得这个App没人维护了，稳定的版本节奏本身就是信任的一部分。

第三件事，养成灰度习惯。重大改动先小范围推送，观察崩溃率和用户反馈，没问题再全量放开。尤其是涉及本地数据结构变更的改动，更容易翻车，灰度能帮你把大部分线上事故挡在门外。只要数据存储结构变了，我几乎必做灰度，哪怕用户量不大，也养成这个流程化习惯。

6. 常见问题速查与避坑实录

6.1 高频报错与排查思路

把开发中遇到的高频问题整理成一张速查表，卡壳的时候对照着排查。这些几乎是我和身边做鸿蒙开发的朋友公认的“新手七宗罪”，遇到一个少一个：

现象 | 常见原因 | 排查思路 |

构建失败，提示签名错误 | 证书或Profile不匹配 | 核对包名和签名指纹，重新导入 |

真机安装失败 | 调试Profile不对或设备未认证 | 检查调试证书，重新认证设备 |

页面白屏 | 页面未注册或初始化异常 | 查module.json5配置，看崩溃日志 |

UI数据变了不刷新 | 变量缺状态装饰器 | 检查是否用@State等装饰器声明 |

网络请求失败 | 权限未申请或域名未配置 | 检查权限声明和网络安全配置 |

模拟器启动卡顿 | 内存不足或镜像版本不符 | 关闭无关程序，核对镜像版本 |

遇到报错，我的第一反应永远是先查官方文档对应章节，其次再搜开发者社区。社区方案要先看版本兼容性，一年前的解法放到新SDK上可能已经失效，对照版本再采纳。这里多提醒一句：不要照搬旧版本的代码，鸿蒙API演进速度很快，有些老的API在新版本里已经废弃，直接拷过来大概率编译不过。

6.2 性能优化要养成的几个习惯

性能优化不是项目做完才做的事，而是开发过程中就要养成的肌肉记忆。等到App卡了再去优化，往往已经陷入了牵一发动全身的局面。下面几个习惯是我做项目时坚持最久、收益也最直接的。

列表类页面用好懒加载。List天生从当前可见区域开始渲染，屏幕外的项不会一次性全渲染，这个机制要靠正确写法去配合。别在ListItem里放重量级计算，也别在滚动回调里做耗时操作，这些地方一卡，用户感知最明显。

状态更新范围尽量小。状态变化会引起组件刷新，范围越小开销越低。把频繁变化的状态放到局部组件，避免一个大状态带动整棵组件树重建。很多人喜欢把所有数据都挂在一个大对象上，图省事，结果每改一个字段整页都跟着刷，这是性能杀手。

图片资源别偷懒。能用WebP就别用大尺寸PNG，列表图片要配合缩略图和占位图。图片是内存占用的大头，优化收益非常直接。我见过一个App光图片就占了一半内存，换了格式和缩略图之后，流畅度提升立竿见影。

注意资源释放。事件监听、定时器在页面销毁时一定要解绑，这是内存泄漏最常见的来源。养成在生命周期结束时清理资源的习惯，越早越好。内存泄漏不像崩溃那么明显，但积累到一定程度会表现为越用越卡，排查起来比崩溃还麻烦。

6.3 给后来者的实在建议

最后说几句掏心窝的话。学习鸿蒙开发，最大的敌人不是技术难度，而是信息差和半途而废。网上资料质量参差不齐，尤其要警惕那些还在讲老架构、老写法的教程，辛苦学完发现新版全变了，特别打击信心。认准官方文档和官方示例，是规避信息差最有效的办法。

另一个建议是尽早做一个完整的小项目。功能再简单，也要从建工程、写页面、做交互到打包上架完整走一遍；这种对全链路生态的认知，看多少教程都换不来。我见过太多人收藏了上百篇教程，连一个像样的 Demo 都没跑完，这比不学还可惜。教程是地图，项目才是真正的路。

还有一件事，多读别人的开源项目。读代码是提升最快的路径，看别人怎么组织目录、怎么处理边界情况、怎么写工具函数，比自己闷头摸索快得多。看完试着改一个功能、加一个页面，改完你就真的会了。代码能力从来不是看出来的，是改出来的。

大概是因为自己淋过雨，所以想把这些伞都塞给你。这套从零基础到 App 上线的完整流程，希望你能真正用起来，而不是放在收藏夹里吃灰。等你跑通第一个上线的应用，再回头看这篇文章，就会发现，曾经觉得遥不可及的路，原来真的就那么几步。