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

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- [一、电商 App 真正复杂的是什么](#一、电商 App 真正复杂的是什么)
- 二、为什么传统页面架构会崩
- 三、真正稳定的电商鸿蒙架构
- 四、先拆"领域"
- - 推荐结构
  - 为什么必须拆领域
- 五、商品系统设计
- - [Product Store](#Product Store)
  - [Product Task](#Product Task)
  - [Product System](#Product System)
  - 一个关键点
- 六、购物车为什么最容易失控
- - 正确结构
  - 外部只能：
- 七、订单系统本质是"状态机"
- - 一个订单的生命周期
  - 正确做法
  - [所有状态变化必须经过 Task](#所有状态变化必须经过 Task)
- [八、支付系统为什么必须 Task 化](#八、支付系统为什么必须 Task 化)
- [九、为什么 AI 会重构电商架构](#九、为什么 AI 会重构电商架构)
- [十、鸿蒙为什么特别适合 AI 电商](#十、鸿蒙为什么特别适合 AI 电商)
- 十一、真正优秀的电商鸿蒙项目长什么样
- 十二、一个非常关键的认知
- 十三、推荐一个完整结构
- - [infrastructure 负责什么](#infrastructure 负责什么)
  - [shared 负责什么](#shared 负责什么)
- 十四、总结

引言

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

text 复制代码

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

看起来似乎只是：

text 复制代码

几个页面 + 几个接口

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

text 复制代码

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

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

text 复制代码

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

甚至：

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

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

text 复制代码

巨型页面工程

很多团队最后才发现：

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

而是：

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

这也是为什么：

text 复制代码

架构

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

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

很多人会以为：

text 复制代码

复杂的是页面数量

其实真正复杂的是：

状态流 + Task Flow。

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

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

这些东西一旦混在一起：

text 复制代码

整个系统会迅速失控

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

很多项目初期会这样：

ts 复制代码

loadProducts()
createOrder()
pay()

页面直接：

调接口
改状态
控制流程

最后页面会同时负责：

text 复制代码

UI
业务
状态
流程

结果：

text 复制代码

页面越来越胖

最终：

text 复制代码

没人敢改

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

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

text 复制代码

UI
 ↓
Store
 ↓
Task
 ↓
System
 ↓
Repository

这是非常适合：

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

的一种结构。

四、先拆"领域"

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

text 复制代码

领域

为什么必须拆领域

因为：

text 复制代码

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

它们是：

text 复制代码

不同业务系统

而不是：

text 复制代码

一个页面里的功能

五、商品系统设计

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

text 复制代码

商品列表

其实真正核心是：

text 复制代码

商品状态

例如：

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

Product Store

ts 复制代码

class ProductStore {

  products: Product[] = []

  current?: Product

}

Product Task

ts 复制代码

class LoadProductTask {

  async run(id: string) {

    const product =
      await productSystem.detail(id)

    productStore.current = product

  }

}

Product System

ts 复制代码

class ProductSystem {

  async detail(id: string) {
    return await repository.detail(id)
  }

}

一个关键点

System：

text 复制代码

无状态

Store：

text 复制代码

唯一状态源

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

因为购物车天然具备：

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

很多项目会这样：

ts 复制代码

cart.push(item)

到处乱改，最后：

text 复制代码

购物车状态彻底失控

正确结构

购物车必须：

text 复制代码

Store 中心化

示例：

ts 复制代码

class CartStore {

  items: CartItem[] = []

  add(item: CartItem) {
    this.items.push(item)
  }

}

外部只能：

ts 复制代码

cartStore.add(item)

而不是：

text 复制代码

直接改数组

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

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

text 复制代码

一个页面

而是：

text 复制代码

状态流系统

一个订单的生命周期

text 复制代码

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

正确做法

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

ts 复制代码

class OrderStore {

  orders: Order[] = []

  updateStatus(
    id: string,
    status: string
  ) {

  }

}

所有状态变化必须经过 Task

例如：

text 复制代码

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

都必须：

text 复制代码

走 Task Flow

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

因为支付本质是：

text 复制代码

长事务

例如：

text 复制代码

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

这天然就是：

text 复制代码

Task 系统

示例：

ts 复制代码

class PayTask {

  async run(orderId: string) {

    const payInfo =
      await paySystem.create(orderId)

    const result =
      await paySystem.invoke(payInfo)

    if (result.success) {

      orderStore.updateStatus(
        orderId,
        "paid"
      )

    }

  }

}

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

传统电商：

text 复制代码

用户主动操作

AI 电商：

text 复制代码

AI 主动完成任务

例如：

ts 复制代码

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

AI 可能：

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

如果没有：

text 复制代码

Task 边界
State 边界

整个系统一定：

text 复制代码

彻底混乱

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

因为鸿蒙天然具备：

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

例如，手机：

text 复制代码

浏览商品

平板：

text 复制代码

查看详情

PC：

text 复制代码

完成支付

这些本质上都是：

text 复制代码

同一个 Task Flow

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

不是：

text 复制代码

页面特别多

而是：

text 复制代码

结构极其稳定

通常具备：

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

这些东西：

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

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

很多人以为：

text 复制代码

电商 = 页面工程

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

text 复制代码

任务系统 + 状态系统

因为：

text 复制代码

页面只是结果

真正核心的是：

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

十三、推荐一个完整结构

text 复制代码

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

infrastructure 负责什么

例如：

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

shared 负责什么

例如：

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

十四、总结

如果用一句话总结：

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

商品：

text 复制代码

状态系统

订单：

text 复制代码

状态机系统

支付：

text 复制代码

长事务系统

AI：

text 复制代码

任务调度系统

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

text 复制代码

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

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

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

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

核心业务没有架构化。

记住一句话：

text 复制代码

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

当你真正建立：

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

你会明显感觉到：

text 复制代码

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

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

文章目录

引言

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

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

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

四、先拆"领域"

推荐结构

为什么必须拆领域

五、商品系统设计

Product Store

Product Task

Product System

一个关键点

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

正确结构

外部只能：

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

一个订单的生命周期

正确做法

所有状态变化必须经过 Task

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

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

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

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

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

十三、推荐一个完整结构

infrastructure 负责什么

shared 负责什么

十四、总结