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

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

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

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

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

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

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

引言

如果你已经写过一段时间鸿蒙应用（尤其是用 ArkUI / ArkTS），你大概率会经历这样一个阶段：

页面越写越多
逻辑越堆越散
状态越来越乱

一开始你觉得：

页面 = 功能

所以你的结构通常是：

/pages
 ├── HomePage
 ├── DetailPage
 ├── ProfilePage

每个页面里面：

UI + 请求 + 状态 + 业务逻辑

刚开始没问题。但当业务一复杂，比如：

登录态
全局数据
跨页面联动
复杂交互

问题就来了：

页面开始“承载一切”

你会看到：

Page 文件 800 行+
逻辑到处复制
状态同步混乱

这时候你可能会怀疑：

是不是鸿蒙不适合做复杂 App？

不是，问题的本质只有一个：

你还在用“页面驱动架构”，但系统已经需要“System 驱动架构”

一、传统 App 架构的问题

先看一个典型写法：

// HomePage.ets
@State userInfo = null

onAppear() {
  this.loadUser()
}

loadUser() {
  api.getUser().then(res => {
    this.userInfo = res
  })
}

handleClick() {
  if (this.userInfo.vip) {
    this.doSomething()
  }
}

问题在哪里？

UI 控制数据
UI 写业务逻辑
UI 管状态

换句话说：

页面 = View + Controller + Service + Store

这就是经典问题：

高耦合
难复用
难测试
难扩展

二、一个关键转变：从“页面”到“System”

你必须建立一个新的认知：

页面不应该驱动业务，System 才应该驱动业务

结构从：

用户点击 → 页面处理 → 更新 UI

变成：

用户输入 → System 处理 → Store 变化 → UI 自动更新

核心变化只有一句话：

页面变“薄”，System 变“厚”

三、重新定义四层结构

在鸿蒙 App 中，你可以把结构统一成：

Store（状态）
System（业务规则）
Engine（调度/流程）
UI（展示）

你会发现： 这和“鸿蒙游戏架构”是同一套模型

因为本质都是：

状态驱动系统

四、第一步：把“状态”从页面中剥离

原来写法

@State cartList: Item[] = []

问题：

每个页面一份状态
无法共享
难以同步

改造：全局 Store

// store/CartStore.ts
export class CartStore {
  items: Item[] = []
}

页面只负责“用”：

@State cartStore: CartStore = globalCartStore

此时：

状态开始集中

五、第二步：把“业务逻辑”从页面中剥离

页面写逻辑

addToCart(item) {
  this.cartList.push(item)
}

问题：

逻辑散落
不可复用
无法测试

引入 System

// system/CartSystem.ts
export class CartSystem {

  addItem(store: CartStore, item: Item) {
    store.items.push(item)
  }

  removeItem(store: CartStore, id: string) {
    store.items = store.items.filter(i => i.id !== id)
  }

}

页面变成：

cartSystem.addItem(cartStore, item)

变化很关键：

UI 不再“决定逻辑”，只负责“触发行为”

六、第三步：按“领域”拆 System

不要搞一个：

AppSystem

否则你只是把问题换个地方继续堆。

正确方式：

/system
 ├── UserSystem
 ├── CartSystem
 ├── OrderSystem
 ├── PaymentSystem

每个 System：

只负责一个领域

示例：UserSystem

export class UserSystem {

  login(store: UserStore, userInfo) {
    store.user = userInfo
    store.isLogin = true
  }

  logout(store: UserStore) {
    store.user = null
    store.isLogin = false
  }

}

七、第四步：引入“流程调度层”

当 System 多了以后，你会遇到一个问题：

流程谁来控制？

比如：

下单流程：
校验登录 → 创建订单 → 扣库存 → 支付

你不能写在 UI：

if (!login) return
createOrder()
pay()

否则 UI 又膨胀。

引入 Engine

class OrderEngine {

  userSystem = new UserSystem()
  orderSystem = new OrderSystem()
  paymentSystem = new PaymentSystem()

  submitOrder(store) {

    if (!store.user.isLogin) return

    this.orderSystem.create(store)
    this.paymentSystem.pay(store)

  }

}

这层的意义：

组合 System
控制流程
隔离 UI

八、UI 的最终职责

当你完成这一步之后，UI 会变成：

Button("下单")
  .onClick(() => {
    orderEngine.submitOrder(store)
  })

UI 只做三件事：

展示数据
接收输入
触发行为

不再：

写业务逻辑
管理复杂状态
控制流程

九、对比一下“升级前 vs 升级后”

页面驱动

Page：
  状态 + 逻辑 + 请求 + 流程

结果：

页面爆炸
逻辑复制
维护困难

System 驱动

Store：数据
System：规则
Engine：流程
UI：展示

结果：

结构清晰
逻辑集中
可复用
可测试

十、一个你必须跨过的认知门槛

很多人卡在这里：

“我只是写个 App，有必要这么复杂吗？”

答案是： 不是你想复杂，而是业务一定会复杂

你现在不拆：

未来一定重构
而且更痛

十一、一个更本质的理解

当你完成这次架构升级之后，你会发现：

你写的已经不是：

页面逻辑

而是：

一个“业务状态机系统”

整个 App 的运行，本质是：

用户输入
   ↓
System 处理
   ↓
Store 变化
   ↓
UI 自动更新

十二、和游戏架构的统一

你会突然发现一件很有意思的事情：App 和游戏，本质一样

都是状态系统
都是规则驱动
都是 UI 响应

所以：

鸿蒙的最佳架构，本质是“System 驱动的一致架构”

总结

当你的鸿蒙 App 开始变复杂时，必须完成这次升级：

从：页面驱动
到：System 驱动

最终结构统一为：

Store：唯一状态源
System：业务规则
Engine：流程调度
UI：纯展示层

如果用一句话总结：

鸿蒙 App 的终极形态，不是“页面集合”，而是一个“由 System 驱动的状态流系统”。