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

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

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

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

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

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

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

引言

很多人刚开始用 ArkUI 写鸿蒙 App 时，都会有一种感觉：

状态驱动真舒服
UI 自动刷新真方便
代码比传统 UI 简洁太多

于是项目里开始疯狂加：

• @State
• @Link
• @Prop
• @Observed

刚开始还好。但项目一旦变大，很快就会进入一种熟悉的混乱：

一个状态改了
三个页面一起刷新

甚至：

• 页面数据突然错乱
• UI 莫名其妙更新
• 分布式同步后状态冲突
• AI 接入后状态彻底不可预测

最后整个项目会变成：

“状态一动，全项目一起抖。”

这就是典型的：

状态地狱（State Hell）

一、什么是“状态地狱”

一句话解释：

状态越来越多，但没人知道“谁在控制它”。

最典型的表现

PageA 能改
PageB 能改
System 能改
Service 也能改

最后：

状态来源彻底失控

二、为什么鸿蒙更容易进入“状态地狱”

因为 ArkUI 的核心机制是：

状态驱动 UI。

ArkUI 的本质

@State count: number = 0

状态变化：

自动触发 UI 更新

看起来很优雅，但问题在于：

自动刷新越强，状态污染越危险。

三、第一种状态地狱：页面变成“状态仓库”

很多页面最后会写成这样：

@State user: User
@State orders: Order[]
@State loading: boolean
@State currentTab: number
@State showDialog: boolean
@State keyword: string

最后：

一个页面管理几十个状态

问题是什么？页面承担了：

• UI
• 数据
• 业务逻辑
• 流程状态

页面变成：

一个巨型状态容器

正确做法

页面只保留“UI 状态”，例如：

@State showDialog: boolean
@State loading: boolean

业务状态放 Store

userStore.user
orderStore.orders

原则：

页面只负责“展示”，不负责“存储业务”。

四、第二种状态地狱：多个地方同时修改状态

这是最危险的问题。

错误写法

PageA 修改 user
PageB 修改 user
System 修改 user

最后：

谁最后写入，谁生效

甚至：

不同设备状态互相覆盖

正确原则

一个状态，只允许一个“写入口”。

示例：

class UserStore {

  user: User

  update(user: User) {
    this.user = user
  }

}

外部只能：

userStore.update(...)

而不是：

this.user = xxx

到处乱写。

五、第三种状态地狱：业务状态和 UI 状态混在一起

很多人会这样写：

@State currentOrder: Order
@State showPayDialog: boolean

问题：

业务状态 + UI 状态耦合

这会导致：

• UI 改动影响业务
• 页面关闭后业务状态丢失
• 分布式同步异常

正确拆分

UI 状态

@State showDialog: boolean

业务状态

orderStore.currentOrder

原则：

UI 状态属于页面，业务状态属于领域。

六、第四种状态地狱：状态没有生命周期

很多状态：

创建了
但没人销毁

例如：

globalState.tempData = xxx

结果：

• 页面退出了
• 状态还在
• 新页面读取旧数据

最后：

状态越来越脏

正确做法

必须定义：

1 页面级状态，页面销毁即销毁

@State keyword: string

2 会话级状态，任务结束即销毁

taskState.currentOrder

3 全局状态，长期存在

globalState.user

核心：

每个状态都必须有“生命周期”。

七、第五种状态地狱：分布式状态直接驱动 UI

很多人会这样：

@State user = await kvStore.get("user")

问题：

另一设备修改
↓
当前 UI 突然刷新
↓
用户操作被打断

正确做法

增加中间层：

DistributedState
   ↓
Store
   ↓
UI

示例：

class UserStore {

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

}

UI：

aboutToAppear() {
  userStore.sync()
}

UI 永远不要直接依赖：

分布式状态源

八、第六种状态地狱：System 偷偷保存状态

很多项目会这样：

class OrderSystem {

  currentOrder: any

}

问题：

状态来源隐藏

结果：

• 无法追踪
• 无法同步
• 无法恢复

正确原则

System 必须无状态。

正确写法

class OrderSystem {

  async create(order) {
    return await orderService.create(order)
  }

}

System：

只负责“处理”
不负责“存储”

九、真正的问题：状态边界消失了

状态地狱最本质的问题，不是状态太多。而是：

状态没有边界。

你必须明确：

谁拥有状态？

Owner

谁能修改？

Writer

谁能读取？

Reader

生命周期是什么？

Scope

如果这四件事不清晰：

项目一定越来越乱

十、正确的状态架构

推荐一个非常稳定的结构：

三层状态模型

GlobalState（全局）
   ↓
DomainStore（业务）
   ↓
UIState（页面）

1 GlobalState，负责：

• 登录
• 用户
• 设备
• 分布式数据

示例：

globalState.user

2 DomainStore，负责：

• 订单
• 商品
• 搜索
• 购物车

示例：

orderStore.orders

3 UIState，负责：

• Dialog
• Loading
• 动画
• Tab

示例：

@State showDialog: boolean

十一、结合 AI / Agent 架构

AI 最大的问题之一：

状态不可预测。

例如：

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

如果 AI 可以随意改状态：

整个 UI 都会失控

正确做法

AI 只能调用：

Store / Task

例如：

await orderStore.cancel(id)

而不是：

this.orders = []

十二、本质

如果用一句话总结：

状态地狱，本质是“状态失控”。

真正危险的不是：

状态多

而是：

没人知道谁在改状态

一个非常关键的认知

很多开发者会觉得：

ArkUI 最大核心是 UI

其实不是。真正核心是：

状态流（State Flow）

因为：

UI 只是状态的结果

十三、一个推荐的状态流模型

这是非常适合鸿蒙 App 的结构：

User Action
     ↓
Store
     ↓
System
     ↓
Repository
     ↓
Store Update
     ↓
UI Render

示例

用户点击按钮

Button("提交订单")
  .onClick(() => {
    orderStore.submit()
  })

Store 调用 System

class OrderStore {

  async submit() {
    this.loading = true

    const result = await orderSystem.create()

    this.order = result
    this.loading = false
  }

}

System 只负责处理

class OrderSystem {

  async create() {
    return await orderRepository.create()
  }

}

整个过程中：

UI 不直接操作数据
System 不持有状态
Store 成为唯一状态源

这才是：

真正稳定的状态流架构。

十四、为什么 AI 会放大“状态地狱”

传统 App：

用户点一下
状态改一次

AI App：

一次任务
可能连续修改几十个状态

例如：

await agent.run("帮我整理今天的会议")

AI 可能：

• 创建日程
• 更新待办
• 写入笔记
• 发送消息
• 修改提醒

如果没有状态边界：

整个应用会变得不可预测

正确方式

AI 只能：

操作 Store

而不是：

直接改 UI

十五、鸿蒙为什么比传统 App 更依赖“状态设计”

因为鸿蒙天然具备：

• 分布式
• 多设备
• 实时同步
• AI 调度
• Task 流转

这些能力本质上都依赖：

状态一致性。

如果状态设计不好：

设备越多
问题越严重

结语

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

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

真正的问题只有一个：

状态系统没有设计。

记住一句话：

没有边界的状态，
最终一定会吞掉整个项目。

当你真正建立：

• 状态分层
• 唯一写入口
• 生命周期管理
• 无状态 System
• Store 中心化

你会明显感觉到：

项目突然“稳定”了