鸿蒙 App 为什么需要统一状态源？

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- 一、什么是统一状态源
- 二、为什么鸿蒙更需要统一状态源
- 三、最常见的状态灾难
- 四、统一状态源架构
- [五、为什么 Store 比 System 更适合存状态](#五、为什么 Store 比 System 更适合存状态)
- 六、统一状态源如何解决状态同步问题
- 七、统一状态源如何支持分布式
- [八、统一状态源如何支持 Agent](#八、统一状态源如何支持 Agent)
- 九、统一状态源的最佳实践
- 十、一个订单系统实战
- [十一、未来为什么所有鸿蒙 App 都会走向统一状态源](#十一、未来为什么所有鸿蒙 App 都会走向统一状态源)
- 十二、本质

引言

很多鸿蒙开发者刚开始写项目时，都会觉得状态管理是一件很简单的事情。

例如：

ts 复制代码

@State user: User

或者：

ts 复制代码

@State orderList: Order[]

页面刷新了，功能也正常，看起来没有任何问题。于是项目里开始出现：

text 复制代码

PageA 保存用户状态
PageB 保存用户状态

OrderSystem 保存订单状态

MessageSystem 保存消息状态

刚开始：

text 复制代码

项目很小
功能很少

完全感觉不到问题，但随着项目越来越大，很快就会出现一些非常熟悉的现象：

text 复制代码

修改昵称后
部分页面没更新

或者：

text 复制代码

订单已经取消
列表还是旧数据

甚至：

text 复制代码

手机显示A状态
平板显示B状态

最后：

text 复制代码

没人知道哪个状态是真的

这时候项目会进入一种典型状态：

状态来源失控。

而解决这个问题最核心的方法只有一个：

建立统一状态源（Single Source of Truth）。

一、什么是统一状态源

一句话解释：

一个业务状态，只允许存在一个权威来源。

例如，用户信息错误设计：

text 复制代码

PageA.user

PageB.user

ProfileSystem.user

MessageSystem.user

可能同时存在四份数据，结果：

text 复制代码

修改了一份

另外三份没更新

状态立即不一致。

正确设计：

text 复制代码

UserStore.user

整个项目：

text 复制代码

所有地方读取
UserStore.user

形成：

text 复制代码

Single Source of Truth

即：

text 复制代码

唯一真实状态源

二、为什么鸿蒙更需要统一状态源

因为鸿蒙天然具备：

状态驱动
多设备
分布式
实时同步
Agent任务流

这些能力都会放大状态问题。传统App，一个设备、一个状态问题还不明显。

鸿蒙：

text 复制代码

Phone
 ↓
Pad
 ↓
PC
 ↓
TV

多个终端共享同一个业务，如果状态有多个来源：

text 复制代码

同步一定出问题

三、最常见的状态灾难

假设用户昵称，PageA：

ts 复制代码

@State userName = "Tom"

PageB：

ts 复制代码

@State userName = "Tom"

用户修改：

ts 复制代码

userName = "OpenHarmony"

结果：

text 复制代码

PageA更新

PageB没更新

出现：

text 复制代码

状态分裂

本质原因：

text 复制代码

存在多个状态源

四、统一状态源架构

推荐结构：

text 复制代码

UI
 ↓
Store
 ↓
System
 ↓
Repository

关键：

text 复制代码

Store
成为唯一状态源

例如：

ts 复制代码

export class UserStore {

  user?: User

}

页面：

ts 复制代码

userStore.user

订单模块：

ts 复制代码

userStore.user

消息模块：

ts 复制代码

userStore.user

整个项目：

text 复制代码

只存在一份用户数据

五、为什么 Store 比 System 更适合存状态

很多项目会这样：

ts 复制代码

class UserSystem {

  currentUser: User

}

看起来很方便，实际上非常危险。因为：

text 复制代码

System职责是处理

而不是：

text 复制代码

保存状态

正确职责：

text 复制代码

Store
负责状态

System
负责逻辑

例如：

ts 复制代码

class UserSystem {

  async updateUser(user) {

    return repository.update(user)

  }

}

Store：

ts 复制代码

class UserStore {

  user?: User

}

职责完全分离。

六、统一状态源如何解决状态同步问题

例如，用户修改头像。

错误模型：

text 复制代码

PageA修改头像

PageB修改头像

ProfileSystem修改头像

最后，谁最后写入谁生效不可预测。

统一状态源：

text 复制代码

UserStore

成为唯一入口。更新：

ts 复制代码

userStore.updateAvatar(url)

所有页面：

ts 复制代码

读取 userStore.user

状态天然一致。

七、统一状态源如何支持分布式

鸿蒙最大的特点：

text 复制代码

状态跨设备存在

例如，手机修改昵称：

text 复制代码

Tom
 ↓
OpenHarmony

平板：

text 复制代码

自动同步

推荐架构：

text 复制代码

Distributed Store
        ↓
Repository
        ↓
UserStore
        ↓
UI

这里：

text 复制代码

UserStore

依然是：

text 复制代码

唯一状态源

而：

text 复制代码

Distributed Store

只是：

text 复制代码

同步通道

八、统一状态源如何支持 Agent

AI Native 应用里，状态问题会更加严重。例如：

ts 复制代码

await agent.run(
  "帮我取消订单"
)

AI可能：

修改订单
修改库存
修改支付状态
修改消息状态

如果没有统一状态源：

text 复制代码

状态会彻底失控

正确方式：

text 复制代码

Agent
 ↓
Store
 ↓
State Update

例如：

ts 复制代码

orderStore.cancel(orderId)

而不是：

ts 复制代码

this.order.status = "cancel"

到处修改。

九、统一状态源的最佳实践

十、一个订单系统实战

订单创建，Store：

ts 复制代码

class OrderStore {

  orders: Order[] = []

}

提交：

ts 复制代码

async create() {

  const order =
    await orderSystem.create()

  this.orders.push(order)

}

页面：

ts 复制代码

ForEach(
  orderStore.orders
)

这里：

text 复制代码

订单状态
只有一份

整个项目：

text 复制代码

不存在第二份订单数据

十一、未来为什么所有鸿蒙 App 都会走向统一状态源

因为未来应用越来越复杂：

text 复制代码

多设备

多窗口

Agent

Task

分布式

这些能力都有一个共同基础：

状态一致性。

而状态一致性的前提，就是：

text 复制代码

统一状态源

否则：

text 复制代码

设备越多

问题越多

十二、本质

如果用一句话总结：

统一状态源的本质，是让整个系统只相信一个地方的数据。

错误模型：

text 复制代码

多个状态源
 ↓
多个真相
 ↓
状态冲突

正确模型：

text 复制代码

一个状态源
 ↓
一个真相
 ↓
状态一致

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

页面太多
功能太复杂
分布式太难

真正的问题往往只有一个：

状态来源太多。

记住一句话：

text 复制代码

状态越分散，

系统越混乱。

状态越集中，

系统越稳定。

当你的鸿蒙 App 开始建立：

UserStore
OrderStore
MessageStore
AssistantState
TaskState

并让它们成为：

text 复制代码

唯一状态源

你会发现：

text 复制代码

整个项目突然变得可预测了。

而这恰恰是：

中大型鸿蒙 App 能长期演进的基础。