AngstEssenSeele先交代一个背景：这几天我把蜜雪冰城鸿蒙原生版翻来覆去地拆，用 ArkTS 把点单、购物车、门店选择这些核心链路重新走了一遍。这篇是系列第一篇，主要聚焦“从零开始搭一个能跑、能点单、能加购的蜜雪冰城风格 App”，把项目拆解、工程骨架、首页、点单页、购物车一路串完，过程中会把每个关键技术点背后的取舍讲清楚。
为什么选蜜雪冰城这个案例？因为它的业务链路足够典型：首页有品牌展示和活动运营区，点单页有左侧分类、右侧商品列表，商品详情有规格选择（甜度、冰量、加料），再往下是购物车、结算、订单。这一整套交互在电商、餐饮、零售类 App 里几乎一模一样。你把这套流程啃下来，后面做任何同类型商业应用，思路都是通的。
说实话，很多初学者拿 HarmonyOS 练手，做的都是待办事项、计数器、新闻阅读这类 Demo，做完就扔，因为根本没有“业务闭环”的感觉。蜜雪冰城这个案例的妙处在于：它逼着你处理真实业务才有的问题，比如多个页面怎么共享购物车数据、菜单数据量大了怎么筛选、规格弹层怎么回填、门店定位权限怎么申请。这些才是企业做 App 时真正会遇到的坎。
我先把这篇的内容边界说清楚，免得你期望错位：本篇从环境准备写到购物车闭环，包含完整的工程结构、核心代码片段、组件选型理由、状态管理方案，以及真机调试和上架前要注意的事。内容偏实战，不罗列官方文档，默认你已经会装 DevEco Studio、知道 ArkTS 基础语法。如果纯小白，建议先跑一遍官方“创建第一个页面”的教程再回来看。
1. 先别急着写代码：拿到“蜜雪冰城”这类商业 App，要做哪些业务拆解
很多人写 App 的习惯是打开 DevEco Studio，新建工程，然后就开始堆页面。这个习惯做 Demo 没问题，做商业项目必翻车。因为商业 App 的页面之间是有依赖关系的，比如点单页选完规格要能把数据丢给购物车，购物车要能反向影响商品列表的角标，结算页要读取收货地址和门店信息。这些“跨页面数据流”如果不在动手前设计好，后面就是无穷无尽的补丁。
1.1 一杯柠檬水的完整业务链路
把蜜雪冰城 App 的核心链路拆开看，其实就是一条线：浏览 → 选品 → 确认规格 → 加入购物车 → 去结算 → 支付 → 取餐。这个链路里，最重的是“选规格”和“购物车”这两个环节。
我以前做过一个奶茶品牌的小程序，当时团队最大的失误就是没把“规格”这个抽象层做好。什么叫做“规格”？就是你点一杯柠檬水，会遇到甜度（正常糖、少糖、半糖、无糖）、冰量（正常冰、少冰、去冰、热饮）、加料（珍珠、椰果、冰淇淋）这三组选项。每组选项都影响价格和库存。如果你把规格写死在商品详情页里，购物车就会很痛苦——因为购物车要能区分“一杯正常糖少冰加珍珠的柠檬水”和“一杯无糖去冰不加料的柠檬水”是两款不同的商品。所以数据模型必须在一开始就把“商品”和“商品SKU”分开。
用一句话概括业务拆解的核心：你要知道每个页面会改哪些数据，这些数据会流向哪里，谁负责存储，谁负责展示。画一张数据流图比写一百行代码都值钱。
1.2 页面结构设计：App 的主干与分支
蜜雪冰城这类点单 App 的页面结构并不复杂，我拆成三级：
- 一级：首页、点单、订单、我的，四个底部 Tab，这是 App 的主干。
- 二级：门店选择、商品详情、购物车列表、结算页，这些是从主干分支出去的页面。
- 三级：订单跟踪、优惠券、个人资料，这些是相对独立的功能页。
在 HarmonyOS 里实现这种结构，最直接的方式是“主页面用 Tabs 组件承载四个 Tab，二级页面用 Navigation 或路由跳转”。但这里有个非常常见的坑：很多人把每个 Tab 都做成一个独立的 page 路由，导致底部 Tab 切换时页面重新加载，状态全丢。正确做法是：Tabs 的每个 TabContent 内部放一个独立的组件（比如 IndexPage、OrderPage、MinePage），而不是放一个路由页面。这样切换 Tab 只是切换组件显隐，不会销毁状态。
1.3 数据模型：菜单、商品、购物车怎么建模
数据模型是我每次做项目第一个动手的地方。蜜雪冰城 App 的数据模型可以简化成三层：
- 分类（Category）：id、名称、图标。比如“人气推荐”“奶茶”“果茶”“冰淇淋”。
- 商品（Product）：id、名称、分类id、基础价格、图片地址、描述。注意商品本身不包含规格，规格是独立集合。
- 商品规格（Sku）：id、商品id、规格组合（甜度、冰量、加料）、价格、库存。
购物车的数据结构则要按“店铺维度 + 商品维度”组织。为什么带店铺？因为蜜雪冰城有门店概念，如果你做了多个门店切换，购物车必须按门店区分——你不可能在 A 店加了三杯，跑到 B 店还能一起结算。这个细节特别容易被忽略，等做到多门店就麻烦了。
购物车每个条目长这样：
typescript复制interface CartItem {
skuId: string
productName: string
specs: string[] // ["正常糖", "少冰", "加珍珠"]
quantity: number
unitPrice: number
}
我的建议是先用 TypeScript interface 把数据模型定义好，再写页面。因为 ArkTS 是 TypeScript 的超集，前后端数据模型可以共用一套定义，后面对接服务端时不用来回改。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开发环境与工程模板：用 DevEco Studio 把项目骨架搭起来
这一节讲环境，但我不打算教你点“下一步”，只讲几个容易踩坑的决策点。开发 HarmonyOS 应用，目前标准工具就是 DevEco Studio，它内置了模拟器、SDK 管理、签名工具和应用市场接入能力。版本选择上，尽量用最新稳定版，不需要纠结，因为鸿蒙工具链迭代很快，新版本会修复旧版本的编译器和调试器问题。
2.1 工程模板怎么选：Empty Ability 还是 Atomic Service
DevEco Studio 新建项目时会让你选模板，常见的有 E