为什么说鸿蒙 App 是“状态系统”？

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

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

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

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

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

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

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

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

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

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

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

持续写作，持续进阶。

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

文章目录

- 引言
- 一、什么是"状态系统"
- - 对比一下两种模型
  - [鸿蒙 ArkUI](#鸿蒙 ArkUI)
  - 示例对比
- 二、为什么说"状态才是核心"
- - [UI 的本质](#UI 的本质)
- 三、生命周期其实是"状态触发点"
- - 示例
- [四、为什么很多鸿蒙 App 会"写崩"](#四、为什么很多鸿蒙 App 会“写崩”)
- - 常见错误
- 五、状态系统的三层结构
- - 一个完整链路
- 六、结合分布式能力
- - 示例
- [七、结合 AI / Agent](#七、结合 AI / Agent)
- - [AI 执行流程](#AI 执行流程)
  - 示例
- 八、为什么说这是"系统级变化"
- - 过去
  - 现在
- 九、一个完整示例
- - 状态层
  - 页面
  - UI
- 十、总结

引言

很多人做鸿蒙 App 时，还是习惯这样思考：

复制代码

写页面
加按钮
处理点击事件
更新 UI

也就是典型的：

"事件驱动 + 页面驱动"模型

但一旦你开始用 ArkUI 写稍微复杂一点的应用，很快就会遇到这些问题：

UI 不刷新 / 刷新异常
状态错乱（尤其多页面）
分布式同步后 UI 崩溃
AI 接入后逻辑完全失控

这时候你需要意识到一个关键点：

鸿蒙 App，本质上不是"页面系统"，而是"状态系统"。

一、什么是"状态系统"

一句话解释：

UI 只是状态的映射，所有变化都来自状态变化。

对比一下两种模型

传统模型

复制代码

点击按钮
↓
执行逻辑
↓
手动更新 UI

鸿蒙 ArkUI

复制代码

状态变化
↓
自动触发 UI 更新

示例对比

传统写法

ts 复制代码

onClick() {
  this.count++
  this.text.setText(this.count.toString())
}

ArkUI 写法

ts 复制代码

@State count: number = 0

Button("增加")
  .onClick(() => {
    this.count++
  })

UI 自动更新：

复制代码

无需手动操作

二、为什么说"状态才是核心"

因为在 ArkUI 中：

UI 根本没有"主动更新"的能力

UI 的本质

ts 复制代码

build() {
  Text(`${this.count}`)
}

build 是：

复制代码

状态的函数映射

也就是说：

复制代码

UI = f(state)

三、生命周期其实是"状态触发点"

很多人纠结：

复制代码

aboutToAppear
onPageShow

但本质上：

这些都是"状态初始化或更新的时机"

示例

ts 复制代码

aboutToAppear() {
  this.user = { name: "Tom" }
}

本质不是：

复制代码

页面出现

而是：

复制代码

状态发生第一次赋值

四、为什么很多鸿蒙 App 会"写崩"

因为你在用：

复制代码

事件驱动思维

写：

复制代码

状态驱动系统

常见错误

1、在 build 里写逻辑

ts 复制代码

build() {
  this.loadData() 错误
}

结果：

复制代码

无限调用

2、手动控制 UI

ts 复制代码

this.visible = false 错误（非状态）

UI 不更新

3、状态分散

ts 复制代码

PageA.state
PageB.state
Service.state

数据不一致

五、状态系统的三层结构

如果你把鸿蒙 App 看成"状态系统"，它应该是这样的：

1、局部状态（UI 层）

ts 复制代码

@State count: number

控制当前组件

2 、共享状态（页面 / 模块）

ts 复制代码

@Observed user: User

多组件共享

3、全局状态（分布式）

ts 复制代码

globalState.get("user")

多设备共享

一个完整链路

复制代码

GlobalState（分布式）
   ↓
ModuleState（共享）
   ↓
@State（UI）
   ↓
UI 渲染

六、结合分布式能力

一旦进入分布式，状态系统会升级：从单设备状态到跨设备状态

示例

ts 复制代码

await kvStore.put("user", user)

UI：

ts 复制代码

aboutToAppear() async {
  this.user = await kvStore.get("user")
}

本质：

复制代码

UI = 分布式状态映射

七、结合 AI / Agent

在 AI 架构中：一切也是围绕"状态"

AI 执行流程

复制代码

用户输入
↓
AI 解析
↓
更新状态
↓
UI 渲染

示例

ts 复制代码

await agent.run("帮我查订单")
↓
globalState.set("orders", result)

UI 自动更新：

ts 复制代码

Text(this.orders.length.toString())

UI 完全被"状态驱动"

八、为什么说这是"系统级变化"

因为一旦你接受这个模型：你的设计方式会彻底改变：

过去

复制代码

页面怎么跳？
按钮怎么点？

现在

复制代码

状态怎么设计？
数据怎么流动？

这就是：

从 UI 思维 → 状态思维

九、一个完整示例

状态层

ts 复制代码

class AppState {

  async setUser(user) {
    await kvStore.put("user", user)
  }

  async getUser() {
    return await kvStore.get("user")
  }

}

页面

ts 复制代码

@State user: any = null

aboutToAppear() async {
  this.user = await appState.getUser()
}

UI

ts 复制代码

build() {
  if (!this.user) {
    return Text("加载中")
  }

  return Text(this.user.name)
}

没有任何：

复制代码

手动刷新 UI

十、总结

鸿蒙 App，本质是"状态 → UI"的映射系统。

对比：

维度	传统 App	鸿蒙 ArkUI
驱动方式	事件	状态
UI 更新	手动	自动
核心	页面	状态
分布式	困难	天然支持

很多人用鸿蒙写 App，会觉得：

"怎么越写越奇怪？"

原因很简单：

你在用旧的思维，写新的系统。

当你真正理解这一点之后：

复制代码

状态是唯一真相
UI 只是结果

你会发现：

代码更简单
逻辑更清晰
分布式更自然
AI 更容易接入