鸿蒙 App 的“无状态 System”设计

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

• • 引言
  • [一、什么是"无状态 System"](#一、什么是“无状态 System”)
  • • 对比两种设计
  • [二、为什么 System 必须无状态](#二、为什么 System 必须无状态)
  • • [1 分布式环境下，状态不能"藏在某一层"](#1 分布式环境下，状态不能“藏在某一层”)
    • [2 并发问题](#2 并发问题)
    • [3 可测试性](#3 可测试性)
  • 三、正确的架构分层
  • • 推荐模型
  • 四、状态应该放在哪里
  • • [1 UI 层（局部状态）](#1 UI 层（局部状态）)
    • [2 模块层（共享状态）](#2 模块层（共享状态）)
    • [3 全局层（分布式状态）](#3 全局层（分布式状态）)
  • [五、System 的正确职责](#五、System 的正确职责)
  • • [1 编排逻辑](#1 编排逻辑)
    • [2 调度任务](#2 调度任务)
    • [3 聚合能力](#3 聚合能力)
  • [六、结合 Task / Agent 架构](#六、结合 Task / Agent 架构)
  • • 示例
  • [七、一个错误 vs 正确案例](#七、一个错误 vs 正确案例)
  • • 错误写法
    • 正确写法
  • [八、System + 状态的正确关系](#八、System + 状态的正确关系)
  • • 错误模型
    • 正确模型
    • 图示
  • 九、为什么很多项目做不到
  • • [1 惯性思维](#1 惯性思维)
    • [2 想"方便"](#2 想“方便”)
    • [3 不理解分布式](#3 不理解分布式)
  • 十、本质总结
  • • 结语

引言

如果你已经开始用鸿蒙写中大型应用，大概率会遇到一个问题：

System 层越来越重
状态越来越多
逻辑越来越难控

很多人会把各种东西往 System 里塞：

• 当前用户
• 当前订单
• 页面状态
• UI 控制标记

看起来很"集中管理"，但很快就会变成：

一个巨大的状态黑洞

但如果你观察一些结构清晰、可扩展的项目，你会发现一个非常反直觉的设计：

System 层，应该是"无状态的"。

一、什么是"无状态 System"

一句话解释：

System 只负责"处理"，不负责"存储"。

对比两种设计

错误 有状态 System

class OrderSystem {

  currentOrder: any

  create(order) {
    this.currentOrder = order
  }

}

问题：

• 状态来源不清晰
• 多设备同步困难
• 并发冲突严重

正确 无状态 System

class OrderSystem {

  async create(order) {
    return await orderService.create(order)
  }

}

System 不保存任何状态

二、为什么 System 必须无状态

1 分布式环境下，状态不能"藏在某一层"

如果你这样写：

this.currentUser = user

这个状态：

只存在当前设备

但鸿蒙是：

多设备系统

所以：

状态必须在"全局可访问"的地方

2 并发问题

有状态 System：

this.currentOrder = orderA
this.currentOrder = orderB

会发生：

状态覆盖

无状态 System：

create(orderA)
create(orderB)

没有冲突

3 可测试性

有状态：

测试依赖历史状态 错误

无状态：

输入 → 输出 ✔

更容易测试

三、正确的架构分层

推荐模型

UI（展示）
   ↓
State（状态）
   ↓
System（处理）
   ↓
Service（业务）
   ↓
Repository（数据）

关键：

状态不属于 System

四、状态应该放在哪里

1 UI 层（局部状态）

@State count: number

2 模块层（共享状态）

class UserState {
  user: any
}

3 全局层（分布式状态）

await kvStore.put("user", user)

System 不应该有：

任何 state 字段

五、System 的正确职责

1 编排逻辑

class OrderSystem {

  async createOrder(itemId: string) {
    const item = await productService.get(itemId)
    return await orderService.create(item)
  }

}

2 调度任务

await task.run()

3 聚合能力

await Promise.all([
  userService.getUser(),
  orderService.list()
])

System 是：

"指挥者"

而不是：

"存储者"

六、结合 Task / Agent 架构

在 AI / Task 模型下： System 更应该无状态

示例

class BuySystem {

  async run(params) {
    return await orderService.create(params.itemId)
  }

}

每次调用：

都是独立的

七、一个错误 vs 正确案例

错误写法

class CartSystem {

  items: any[] = []

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

}

问题：

• 状态不透明
• 不可分布式
• 不可恢复

正确写法

class CartSystem {

  async add(item) {
    const cart = await globalState.get("cart") || []
    cart.push(item)
    await globalState.set("cart", cart)
  }

}

状态：

外部存储

八、System + 状态的正确关系

错误模型

System 持有状态 错误

正确模型

System 使用状态 正确

图示

State → System → State

System：

只做"变换"

九、为什么很多项目做不到

1 惯性思维

写类 → 加属性 → 存数据

2 想"方便"

先存在这里再说

3 不理解分布式

以为是单机应用

结果：

越写越乱

十、本质总结

如果用一句话总结：

System 应该是"纯函数式"的能力层。

对比：

维度	有状态 System	无状态 System
状态来源	内部	外部
可扩展性	差	强
分布式	困难	自然
可测试性	差	好

结语

很多鸿蒙项目后期难维护，本质原因是：

System 层承担了"它不该承担的责任"。

当你把 System 改成"无状态"之后，你会明显感受到：

• 逻辑更清晰
• 状态更可控
• 分布式更容易
• AI 更容易接入

记住一句话：

状态是"数据"
System 是"函数"