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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

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

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

也就是典型的：

“事件驱动 + 页面驱动”模型

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

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

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

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

一、什么是“状态系统”

一句话解释：

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

对比一下两种模型

传统模型

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

鸿蒙 ArkUI

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

示例对比

传统写法

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

ArkUI 写法

@State count: number = 0

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

UI 自动更新：

无需手动操作

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

因为在 ArkUI 中：

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

UI 的本质

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

build 是：

状态的函数映射

也就是说：

UI = f(state)

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

很多人纠结：

aboutToAppear
onPageShow

但本质上：

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

示例

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

本质不是：

页面出现

而是：

状态发生第一次赋值

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

因为你在用：

事件驱动思维

写：

状态驱动系统

常见错误

1、在 build 里写逻辑

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

结果：

无限调用

2、手动控制 UI

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

UI 不更新

3、状态分散

PageA.state
PageB.state
Service.state

数据不一致

五、状态系统的三层结构

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

1、局部状态（UI 层）

@State count: number

控制当前组件

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

@Observed user: User

多组件共享

3、 全局状态（分布式）

globalState.get("user")

多设备共享

一个完整链路

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

六、结合分布式能力

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

示例

await kvStore.put("user", user)

UI：

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

本质：

UI = 分布式状态映射

七、结合 AI / Agent

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

AI 执行流程

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

示例

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

UI 自动更新：

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

UI 完全被“状态驱动”

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

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

过去

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

现在

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

这就是：

从 UI 思维 → 状态思维

九、一个完整示例

状态层

class AppState {

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

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

}

页面

@State user: any = null

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

UI

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

  return Text(this.user.name)
}

没有任何：

手动刷新 UI

十、总结

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

对比：

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

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

“怎么越写越奇怪？”

原因很简单：

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

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

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

你会发现：

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