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

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

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

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

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

引言

很多人第一次接触 Store 架构时，都会有一个疑问：

ArkUI 已经有 @State
为什么还需要 Store？

看起来：

@State 能更新UI
@Link 能传递状态
@Observed 能监听变化

似乎已经够用了。但只要项目开始变大，很快就会发现：

状态到处都是
页面互相依赖
业务越来越难维护

最后出现一种熟悉的现象：

改一个状态
整个项目一起刷新

所以在中大型鸿蒙项目里：

Store 不是可选项，而是架构基础设施。

一、什么是 Store

一句话解释：

Store 是应用唯一可信的状态中心。

例如用户信息，错误做法：

PageA.user

PageB.user

PageC.user

三个页面各存一份，结果：

数据不一致

正确做法：

userStore.user

所有页面：

共享同一份状态

结构：

UI
 ↓
Store
 ↓
System
 ↓
Repository

二、为什么鸿蒙 App 必须有 Store

很多项目后期崩掉，本质原因其实只有一个：

状态没有统一管理。

例如：

@State user: User

页面A：

this.user.name = "Tom"

页面B：

this.user.name = "Jack"

结果：

谁最后写入
谁生效

状态来源彻底失控。

Store 的核心作用：

统一状态
统一更新
统一通知

即：

Single Source Of Truth

唯一状态源。

三、Store 应该放什么

很多开发者容易把 Store 做成：

万能仓库

什么都往里面塞，例如：

showDialog
loading
animation
scrollOffset

这其实是不对的。

正确原则，Store 只存：

业务状态

例如：

用户
订单
商品
购物车
消息

示例：

export class UserStore {

  user?: User

}

export class OrderStore {

  orders: Order[] = []

}

四、Store 不应该放什么

第一类：

UI状态

例如：

@State loading = false

@State showDialog = false

这些应该属于：

页面

而不是：

Store

第二类：

临时状态

例如：

keyword

currentInput

这些应该：

页面销毁即销毁

不应该进入全局状态。

五、推荐的 Store 分层

很多项目后期混乱，原因是：

只有一个Store

例如：

appStore

里面：

用户
订单
支付
商品
聊天

全部混在一起。

正确结构：

Global Store
      ↓
Domain Store
      ↓
UI State

第一层 Global Store

负责：

登录
用户
设备
权限

示例：

export class GlobalStore {

  user?: User

  token: string = ""

}

第二层 Domain Store

例如，订单领域

export class OrderStore {

  orders: Order[] = []

}

商品领域

export class ProductStore {

  products: Product[] = []

}

消息领域

export class MessageStore {

  messages: Message[] = []

}

第三层 UI State

例如：

@State showDialog = false

@State loading = false

永远不要进入：

Store

六、Store 和 System 的关系

很多项目有一个严重问题：

System 保存状态

例如：

class OrderSystem {

  currentOrder: Order

}

这会导致：

状态来源隐藏

正确结构：

Store 持有状态
System 处理状态

示例，Store

export class OrderStore {

  currentOrder?: Order

}

System

export class OrderSystem {

  async createOrder() {
    return await repository.create()
  }

}

七、Store 更新的最佳实践

错误写法：

orderStore.orders.push(order)

任何地方都能改，结果：

无法追踪状态来源

正确写法：

class OrderStore {

  private orders: Order[] = []

  add(order: Order) {
    this.orders.push(order)
  }

}

调用：

orderStore.add(order)

核心原则：

状态只能通过 Action 修改。

八、Store + Task 架构

未来鸿蒙 App 会越来越多采用：

Task 驱动

结构：

UI
 ↓
Task
 ↓
Store
 ↓
System

例如，用户点击：

Button("提交订单")

执行：

await taskCenter.run(
  "create_order"
)

Task：

class CreateOrderTask {

  async run() {

    const order =
      await orderSystem.create()

    orderStore.setOrder(order)

  }

}

Store 成为：

任务结果中心

九、Store + AI Agent

AI Native App 最大问题：

AI会修改状态

例如：

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

如果AI直接操作：

orders = []

整个系统会失控。

正确方式，AI只能调用：

orderStore.cancel(id)

或者：

taskCenter.run(
  "cancel_order"
)

即：

AI不能直接修改状态

只能通过：

Store
Task

操作系统。

十、Store + 分布式同步

鸿蒙最大的特点：

多设备

例如：

手机
平板
PC
TV

此时：Store 不仅是状态中心。

还是：

同步中心

例如：

class UserStore {

  async sync() {

    const user =
      await kvStore.get("user")

    this.user = user

  }

}

结构：

Distributed KV
       ↓
Store
       ↓
UI

十一、一个完整示例

订单创建流程：

Button Click
       ↓
Task
       ↓
System
       ↓
Repository
       ↓
Store Update
       ↓
UI Render

UI

Button("创建订单")
.onClick(() => {

  orderStore.create()

})

Store

class OrderStore {

  order?: Order

  async create() {

    const result =
      await orderSystem.create()

    this.order = result

  }

}

System

class OrderSystem {

  async create() {

    return await repository.create()

  }

}

Repository

class OrderRepository {

  async create() {

    return http.post("/order")

  }

}

整个链路：

职责明确
状态唯一
逻辑清晰

十二、未来鸿蒙 App 的 Store 演进

早期：

Page
 ↓
State

中期：

Page
 ↓
Store
 ↓
System

未来 AI Native：

Intent
 ↓
Task
 ↓
Store
 ↓
System
 ↓
Repository

Store 将成为：

整个应用状态中枢

总结

如果用一句话总结 Store：

Store 不是状态容器，而是整个应用的数据秩序。

很多鸿蒙项目后期失控，并不是因为：

• 页面太多
• 功能太复杂
• AI 太难接入

真正的问题只有一个：

状态没有唯一来源。

记住一个非常重要的原则：

UI负责展示
Store负责状态
System负责处理
Repository负责数据

当你真正建立：

统一Store
领域Store
唯一写入口
Task驱动
无状态System

你会明显感受到：

项目开始变得可预测

而这也是中大型鸿蒙 App 能够长期演进的关键基础。