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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、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

class ProductStore {

  products: Product[] = []

  current?: Product

}

Product Task

class LoadProductTask {

  async run(id: string) {

    const product =
      await productSystem.detail(id)

    productStore.current = product

  }

}

Product System

class ProductSystem {

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

}

一个关键点

System：

无状态

Store：

唯一状态源

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

因为购物车天然具备：

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

很多项目会这样：

cart.push(item)

到处乱改，最后：

购物车状态彻底失控

正确结构

购物车必须：

Store 中心化

示例：

class CartStore {

  items: CartItem[] = []

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

}

外部只能：

cartStore.add(item)

而不是：

直接改数组

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

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

一个页面

而是：

状态流系统

一个订单的生命周期

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

正确做法

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

class OrderStore {

  orders: Order[] = []

  updateStatus(
    id: string,
    status: string
  ) {

  }

}

所有状态变化必须经过 Task

例如：

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

都必须：

走 Task Flow

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

因为支付本质是：

长事务

例如：

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

这天然就是：

Task 系统

示例：

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 会重构电商架构

传统电商：

用户主动操作

AI 电商：

AI 主动完成任务

例如：

await agent.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 调度边界
• 分布式状态流

你会明显感觉到：

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