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

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

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

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

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

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

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

引言

很多开发者第一次接触 ArkUI（ArkTS）时，都会有一种感觉：

这也太简单了。

一个页面可能只需要几十行代码：

Column() {
  Text("Hello ArkUI")
  Button("Click")
}

没有复杂的 XML，没有繁琐的生命周期，看起来比传统开发简单太多。于是很多人会觉得：

ArkUI 上手很容易，开发成本很低。

但当你真正做一个中大型项目时，就会发现现实完全不同：

状态越来越乱
组件越来越难拆
刷新问题难以定位
代码越来越难维护

甚至会出现一种很典型的情况：

项目能跑，但没人敢动。

这就引出了一个问题：

为什么 ArkUI 看起来简单，却很难写好？

表面简单：因为“隐藏了复杂性”

ArkUI 之所以让人觉得简单，是因为它做了一件事：

把很多复杂性隐藏了。

例如：

状态更新
UI刷新
组件生命周期
数据绑定

在 ArkUI 中，很多事情变成了：

this.count++

UI 自动刷新，但问题是：

复杂性并没有消失，只是换了位置。

开发者不再手动控制 UI 更新，但需要理解：

什么时候刷新
为什么刷新
为什么不刷新

如果不理解这些机制，就很容易踩坑。

难点 1：状态驱动带来的“隐式逻辑”

在传统开发中，逻辑通常是显式的：

调用方法 → 更新 UI

但在 ArkUI 中，逻辑变成：

修改状态 → UI 自动变化

例如：

@State count: number = 0

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

看起来很简单，但当状态变多时：

@State a
@State b
@State c

你会很难判断：

哪个状态影响哪个 UI
哪个操作触发了刷新
为什么某个组件刷新了

这就是典型的：

隐式依赖问题。

难点 2：组件边界不清晰

很多开发者在写 ArkUI 时，会遇到一个问题：

组件到底该怎么拆？

例如：

一个页面拆成几个组件？
组件应该多大？
状态放在哪里？

如果拆得太细：

组件很多
结构复杂
阅读困难

如果拆得太粗：

复用性差
逻辑耦合
难以维护

ArkUI 本身并没有强制规范，这就导致：

组件设计完全依赖开发者经验。

难点 3：状态作用域容易混乱

ArkUI 提供了多种状态：

@State
@Prop
@Link
@Provide
@Consume

但很多项目中会出现：

状态随便用
边界不清晰
数据流混乱

例如：

@State user
@Prop user
@Link user

同一个数据在多个地方存在，结果就是：

数据不同步
修改难以追踪
bug 难以定位

本质问题是：

没有设计清晰的状态边界。

难点 4：刷新机制不好理解

很多 ArkUI 的问题，本质都和刷新有关，例如常见问题：

为什么 UI 没刷新？
为什么整个页面刷新了？
为什么子组件没更新？

例如这个代码：

@State user: User = new User()

this.user.name = "Tom"

UI 不会更新，原因是：

ArkUI 依赖引用变化，而不是内部属性变化。

这类问题如果不理解机制，很难排查。

难点 5：业务逻辑容易“长在 UI 里”

很多 ArkUI 项目会变成这样：

Column() {
  Text(this.user.name)

  Button("提交")
    .onClick(() => {
      // 校验
      // 请求
      // 更新状态
    })
}

看起来很直观，但随着逻辑变多：

UI代码变复杂
逻辑难复用
测试困难

最终页面变成：

UI + 业务 + 状态 混在一起。

难点 6：缺少“约束”，自由度太高

ArkUI 有一个特点：

非常灵活。

你可以：

状态随便放
组件随便拆
逻辑随便写

这在小项目中是优势，但在大项目中就变成：

没有规范
风格混乱
难以协作

很多团队的问题其实不是技术问题，而是：

缺少统一约束。

为什么很多项目后期会失控

结合上面的问题，可以总结一个现象，ArkUI 项目在初期通常是：

开发快
结构简单
迭代迅速

但到了中后期：

状态爆炸
组件混乱
逻辑耦合
维护困难

原因很简单：

前期“简单”，是因为规模还不够大。

如何把 ArkUI 写好

虽然 ArkUI 有这些难点，但并不是不能解决，关键在于几个原则。

1 明确状态边界

局部状态 → @State
组件通信 → @Prop / @Link
全局状态 → Store + @Provide/@Consume

避免：

一个数据多个来源

2 UI 和逻辑分离

不要在 UI 中写业务逻辑：

// 不推荐
Button().onClick(() => {
  this.submit()
})

而是：

// 推荐
Button().onClick(() => {
  viewModel.submit()
})

3 组件按“业务语义”拆分

优先拆：

UserCard
OrderItem
ProductCard

而不是：

Box
Wrapper
Container

4 状态集中管理

使用：

Store
ViewModel

统一管理数据。

5 建立团队规范

例如：

状态使用规则
组件拆分规则
目录结构
命名规范

这些比技术本身更重要。

总结

ArkUI 给人的第一印象是：

简单、轻量、易上手。

但真正难的地方在于：

状态驱动带来的隐式逻辑
组件边界设计
状态作用域管理
刷新机制理解
UI与业务解耦
团队规范建设

也就是说：

难的不是语法，而是设计。

很多开发者写不好 ArkUI，不是因为不会写代码，而是因为：

没有把它当成“架构问题”来处理。

当你开始用“架构思维”去写 ArkUI 时，你会发现：它其实并不复杂。但如果只是“想到哪写到哪”，最终很容易走向一个结局：

代码能跑，但没人敢改。