一个电商鸿蒙 App 的架构设计实战

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人第一次做鸿蒙电商 App 时，都会觉得：

电商不就是： 首页 商品 购物车 订单 支付

看起来似乎只是：

几个页面 + 几个接口

于是项目初期通常会这样：

页面直接调接口 接口返回直接渲染 按钮点击直接支付

刚开始开发速度非常快。但只要业务开始增长，很快就会进入一种熟悉的状态：

购物车状态越来越乱 订单流程越来越复杂 支付逻辑越来越难控

甚至：

• AI 推荐接不进去
• 多设备状态同步异常
• 分布式能力越来越混乱
• 页面之间互相依赖

最后整个项目会慢慢变成：

巨型页面工程

很多团队最后才发现：

电商真正难的，从来不是“页面”。

而是：

复杂业务系统之间的协同。

这也是为什么：

架构

永远是电商鸿蒙 App 的核心。

一、电商 App 真正复杂的是什么

很多人会以为：

复杂的是页面数量

其实真正复杂的是：

状态流 + Task Flow。

因为一个电商系统天然具备：

• 登录状态
• 商品状态
• 库存状态
• 购物车状态
• 订单状态
• 支付状态
• 分布式同步
• AI 推荐
• 多设备协同

这些东西一旦混在一起：

整个系统会迅速失控

二、为什么传统页面架构会崩

很多项目初期会这样：

loadProducts()createOrder()pay()

页面直接：

• 调接口
• 改状态
• 控制流程

最后页面会同时负责：

UI 业务 状态 流程

结果：

页面越来越胖

最终：

没人敢改

三、真正稳定的电商鸿蒙架构

推荐一个非常稳定的结构：

UI ↓ Store ↓ Task ↓ System ↓ Repository

这是非常适合：

• AI 电商
• 分布式鸿蒙
• 多设备协同

的一种结构。

四、先拆“领域”

真正优秀的电商系统，一定会先拆：

领域

推荐结构

app/ ├── auth/ ├── product/ ├── cart/ ├── order/ ├── pay/ ├── message/ ├── ai/ └── shared/

为什么必须拆领域

因为：

购物车 ≠ 订单 订单 ≠ 支付 支付 ≠ 用户

它们是：

不同业务系统

而不是：

一个页面里的功能

五、商品系统设计

商品系统核心是什么？很多人以为：

商品列表

其实真正核心是：

商品状态

例如：

• 库存
• SKU
• 价格
• 推荐状态
• AI 标签
• 分布式同步

Product Store

classProductStore{products:Product[]=[]current?:Product}

Product Task

classLoadProductTask{asyncrun(id:string){constproduct=awaitproductSystem.detail(id)productStore.current=product}}

Product System

classProductSystem{asyncdetail(id:string){returnawaitrepository.detail(id)}}

一个关键点

System：

无状态

Store：

唯一状态源

六、购物车为什么最容易失控

因为购物车天然具备：

• 本地状态
• 登录同步
• 分布式同步
• AI 自动加购
• 多设备共享

很多项目会这样：

cart.push(item)

到处乱改，最后：

购物车状态彻底失控

正确结构

购物车必须：

Store 中心化

示例：

classCartStore{items:CartItem[]=[]add(item:CartItem){this.items.push(item)}}

外部只能：

cartStore.add(item)

而不是：

直接改数组

七、订单系统本质是“状态机”

这是很多电商项目最大的核心，订单绝对不是：

一个页面

而是：

状态流系统

一个订单的生命周期

待支付 ↓ 已支付 ↓ 待发货 ↓ 运输中 ↓ 已完成

正确做法

订单状态必须统一管理，示例：

classOrderStore{orders:Order[]=[]updateStatus(id:string,status:string){}}

所有状态变化必须经过 Task

例如：

支付成功 取消订单 自动退款

都必须：

走 Task Flow

八、支付系统为什么必须 Task 化

因为支付本质是：

长事务

例如：

创建支付单 ↓ 拉起 SDK ↓ 等待回调 ↓ 校验签名 ↓ 更新订单

这天然就是：

Task 系统

示例：

classPayTask{asyncrun(orderId:string){constpayInfo=awaitpaySystem.create(orderId)constresult=awaitpaySystem.invoke(payInfo)if(result.success){orderStore.updateStatus(orderId,"paid")}}}

九、为什么 AI 会重构电商架构

传统电商：

用户主动操作

AI 电商：

AI 主动完成任务

例如：

awaitagent.run("帮我买最适合的显示器")

AI 可能：

• 搜索商品
• 比较参数
• 加购物车
• 创建订单
• 自动支付

如果没有：

Task 边界 State 边界

整个系统一定：

彻底混乱

十、鸿蒙为什么特别适合 AI 电商

因为鸿蒙天然具备：

• 多设备
• 分布式
• 实时状态同步
• Task 流转
• AI 调度能力

例如，手机：

浏览商品

平板：

查看详情

PC：

完成支付

这些本质上都是：

同一个 Task Flow

十一、真正优秀的电商鸿蒙项目长什么样

不是：

页面特别多

而是：

结构极其稳定

通常具备：

• Store 中心化
• Task 驱动
• 无状态 System
• 领域拆分
• 分布式状态同步
• AI Task Flow

这些东西：

决定项目后期还能不能继续迭代。

十二、一个非常关键的认知

很多人以为：

电商 = 页面工程

其实真正的电商系统更像：

任务系统 + 状态系统

因为：

页面只是结果

真正核心的是：

• 状态流
• Task Flow
• 业务边界
• 分布式同步

十三、推荐一个完整结构

app/ ├── auth/ ├── product/ ├── cart/ ├── order/ ├── pay/ ├── ai/ ├── shared/ └── infrastructure/

infrastructure 负责什么

例如：

• 网络
• 分布式同步
• AI 调度
• 日志
• 监控
• Task Runtime

shared 负责什么

例如：

• UI 组件
• 通用状态
• 基础模型
• 工具能力

十四、总结

如果用一句话总结：

电商鸿蒙 App，本质上是“Task + State”的复杂系统。

商品：

状态系统

订单：

状态机系统

支付：

长事务系统

AI：

任务调度系统

未来真正稳定的鸿蒙电商架构一定会越来越明显：

页面外围化 Task 中心化 State 核心化

很多电商鸿蒙项目后期越来越难维护，并不是因为：

• 页面太多
• 接口太复杂
• AI 太难接

真正的问题其实只有一个：

核心业务没有架构化。

记住一句话：

电商真正复杂的， 从来不是页面， 而是状态与任务。

当你真正建立：

• Store 中心化
• Task Flow
• 无状态 System
• 领域拆分
• AI 调度边界
• 分布式状态流

你会明显感觉到：

整个鸿蒙电商系统终于“稳定”了