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

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

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

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

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

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

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

引言

很多鸿蒙 App 在早期都会有一段“顺风期”：

• 页面不多
• 逻辑简单
• 需求推进很快
• 迭代几乎没有阻力

这时候，代码怎么写都能跑。

但只要项目继续长大，一种熟悉的感觉就会慢慢出现：

每加一个功能，都像在拉一根快要断掉的线。

改 UI 会牵动业务，动状态会影响能力，修一个 Bug 能连锁改三层。

直到某一刻你才意识到：

问题不是复杂度太高，而是——三层从一开始就没有分开。

而在大型鸿蒙 App 里，这件事就是第一道真正的生死线：

UI、状态、能力，必须彻底解耦。

第一层错觉：代码还能维护，只是“有点乱”

大多数团队第一次警觉，是在代码开始变成这样：

// Page.ets
build() {
  Column() {
    Button('提交')
      .onClick(() => {
        this.loading = true
        http.post('/submit', this.formData).then(res => {
          this.loading = false
          this.result = res.data
        })
      })
  }
}

看起来没问题：

• UI 在页面里
• 状态在页面里
• 请求也在页面里

一切都很自然。

但问题是——

这种“自然”，只在项目很小的时候成立。

当页面数量、业务复杂度、团队规模同时上升时：

• 任何改动都无法局部收敛
• 状态边界开始模糊
• 能力调用四处散落

系统开始进入一种危险状态：

还能跑，但已经不可控。

第二层真相：三层不分，复杂度一定指数增长

为什么问题一定会发生？因为 UI、状态、能力本来就属于完全不同的维度：

UI：短生命周期、强变化

• 频繁改版
• 强依赖交互
• 可以被随时销毁重建

@State loading: boolean = false

UI 天生就是不稳定层。

状态：中生命周期、需要连续性

• 跨页面存在
• 影响业务流程
• 需要可o保持一致

class OrderState {
  status: 'idle' | 'submitting' | 'success'
}

状态必须独立于 UI，否则页面一销毁：

业务上下文直接断裂。

能力：长生命周期、最稳定

• 网络
• 存储
• 设备能力
• 服务通信

class OrderService {
  submit(data) {
    return http.post('/submit', data)
  }
}

能力层本质上是：

整个 App 最不应该频繁变化的部分。

第三层崩塌路径：为什么大型项目一定会失控

当三层混在一起时，会出现一个必然过程：

UI 改动 ： 触发状态重构

if (isTablet) {
  this.formData = newForm
}

UI 变化直接改变业务数据结构。

状态变化 ：牵动能力实现

if (this.isNewFlow) {
  http.post('/v2/submit')
}

状态逻辑侵入服务层。

能力升级 ： 反向冲击 UI

// 接口字段变化
this.result.name -> this.result.title

页面大面积修改。

最终形成一个典型症状：

任何修改，都会变成“全局手术”。

这就是大型鸿蒙 App 最常见的失控起点。

第四层关键：真正的“三层解耦”是什么

很多人以为解耦只是：

• 抽几个 util
• 分几个文件夹
• 加一层 ViewModel

但真正的三层解耦，核心不是结构，而是依赖方向：

UI ： 只能依赖状态
状态 ： 只能依赖能力
能力 ： 不能反向依赖任何上层

我们用最小模型来看。

能力层：纯服务，不感知 UI

class OrderService {
  async submit(data: SubmitDTO) {
    return http.post('/submit', data)
  }
}

禁止出现：

• @State
• 页面引用
• UI 回调

能力层必须是绝对纯净的底座。

状态层：只编排业务，不碰 UI

class OrderStore {
  constructor(private service: OrderService) {}

  status: 'idle' | 'loading' | 'success' = 'idle'

  async submit(data) {
    this.status = 'loading'
    await this.service.submit(data)
    this.status = 'success'
  }
}

注意这里最重要的一点：

状态变化 = 业务语义，而不是 UI 行为。

UI 层：只做展示与交互绑定

Button('提交')
  .onClick(() => store.submit(this.formData))

if (store.status === 'loading') {
  LoadingView()
}

UI 不再关心：

• 接口地址
• 提交逻辑
• 数据结构细节

它只关心：

“现在是什么状态，我该怎么展示。”

第五层工程意义：为什么这是“生死线”

当三层真正分开后，会出现几个决定性的变化：

需求复杂度开始下降

因为：

改 UI 不再动业务，改业务 不再改能力。

复杂度第一次被切断传播路径。

Bug 范围被强制收敛

• UI Bug ：只在 UI
• 状态 Bug ： 不影响界面结构
• 能力 Bug ： 不污染业务流程

系统从“全局不确定”，变成：

局部可控。

团队协作才真正成立

没有解耦时：

• 谁改代码都可能炸全局

解耦之后：

• UI、业务、底层可以并行推进

这才是：

大型工程真正能持续演进的前提。

第六层现实：为什么很多项目过不了这一关

因为三层解耦有一个非常残酷的特点：

它在前期几乎没有“可见收益”。

• 不能立刻提升性能
• 不能马上减少 Bug
• 甚至开发速度会暂时变慢

但它决定的是：

项目半年之后还能不能继续写。

所以大多数失败项目，并不是技术不行，而是：

在最该重构的时候，选择了继续堆功能。

总结

回头看大型鸿蒙 App 的演进路径，你会发现一个清晰分界：

解耦之前：

• 功能越多，系统越脆
• 修改一次，牵动全局
• 团队规模越大，风险越高

解耦之后：

• 复杂度被分层锁住
• 改动开始局部收敛
• 架构第一次真正稳定

所以这件事才会被称为：

大型鸿蒙 App 的第一道生死线。