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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

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

例如：

@State user: User

或者：

@State orderList: Order[]

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

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

OrderSystem 保存订单状态

MessageSystem 保存消息状态

刚开始：

项目很小
功能很少

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

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

或者：

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

甚至：

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

最后：

没人知道哪个状态是真的

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

状态来源失控。

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

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

一、什么是统一状态源

一句话解释：

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

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

PageA.user

PageB.user

ProfileSystem.user

MessageSystem.user

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

修改了一份

另外三份没更新

状态立即不一致。

正确设计：

UserStore.user

整个项目：

所有地方读取
UserStore.user

形成：

Single Source of Truth

即：

唯一真实状态源

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

因为鸿蒙天然具备：

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

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

鸿蒙：

Phone
 ↓
Pad
 ↓
PC
 ↓
TV

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

同步一定出问题

三、最常见的状态灾难

假设用户昵称，PageA：

@State userName = "Tom"

PageB：

@State userName = "Tom"

用户修改：

userName = "OpenHarmony"

结果：

PageA更新

PageB没更新

出现：

状态分裂

本质原因：

存在多个状态源

四、统一状态源架构

推荐结构：

UI
 ↓
Store
 ↓
System
 ↓
Repository

关键：

Store
成为唯一状态源

例如：

export class UserStore {

  user?: User

}

页面：

userStore.user

订单模块：

userStore.user

消息模块：

userStore.user

整个项目：

只存在一份用户数据

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

很多项目会这样：

class UserSystem {

  currentUser: User

}

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

System职责是处理

而不是：

保存状态

正确职责：

Store
负责状态

System
负责逻辑

例如：

class UserSystem {

  async updateUser(user) {

    return repository.update(user)

  }

}

Store：

class UserStore {

  user?: User

}

职责完全分离。

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

例如，用户修改头像。

错误模型：

PageA修改头像

PageB修改头像

ProfileSystem修改头像

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

统一状态源：

UserStore

成为唯一入口。更新：

userStore.updateAvatar(url)

所有页面：

读取 userStore.user

状态天然一致。

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

鸿蒙最大的特点：

状态跨设备存在

例如，手机修改昵称：

Tom
 ↓
OpenHarmony

平板：

自动同步

推荐架构：

Distributed Store
        ↓
Repository
        ↓
UserStore
        ↓
UI

这里：

UserStore

依然是：

唯一状态源

而：

Distributed Store

只是：

同步通道

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

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

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

AI可能：

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

如果没有统一状态源：

状态会彻底失控

正确方式：

Agent
 ↓
Store
 ↓
State Update

例如：

orderStore.cancel(orderId)

而不是：

this.order.status = "cancel"

到处修改。

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

推荐：

Global Store

负责：

用户
设备
登录
配置

Domain Store

负责：

订单
支付
课程
消息

UI State

负责：

Dialog

Loading

Animation

结构：

GlobalState
      ↓
DomainStore
      ↓
UIState

非常稳定。

十、一个订单系统实战

订单创建，Store：

class OrderStore {

  orders: Order[] = []

}

提交：

async create() {

  const order =
    await orderSystem.create()

  this.orders.push(order)

}

页面：

ForEach(
  orderStore.orders
)

这里：

订单状态
只有一份

整个项目：

不存在第二份订单数据

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

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

多设备

多窗口

Agent

Task

分布式

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

状态一致性。

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

统一状态源

否则：

设备越多

问题越多

十二、本质

如果用一句话总结：

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

错误模型：

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

正确模型：

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

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

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

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

状态来源太多。

记住一句话：

状态越分散，

系统越混乱。

状态越集中，

系统越稳定。

当你的鸿蒙 App 开始建立：

• UserStore
• OrderStore
• MessageStore
• AssistantState
• TaskState

并让它们成为：

唯一状态源

你会发现：

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

而这恰恰是：

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