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

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

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

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

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

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

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

引言

几乎每一个做过中大型鸿蒙项目的团队，都会经历同一段路径：

1. 第一版能跑，但很乱
2. 决心重建架构，推倒重来
3. 第二版结构清晰、分层优雅、状态可控
4. 半年之后，再次变得难改、难测、难扩展

很多人会困惑：

我们不是已经做过一次“正确的架构重建”了吗？
为什么复杂度还是回来了？

真正的答案其实很残酷：

第一次重建，解决的是“代码形态问题”。
但鸿蒙 App 的失控，本质是“系统模型问题”。

第一次架构重建，本质上只修复了表面

团队第一次重建时，通常会做这些事：

• 重新划分模块
• 引入统一状态管理
• 规范路由与生命周期
• 把工具类、业务层、UI 层全部梳理一遍

这一步非常必要，因为它解决的是：

可读性、可维护性、可协作性。

这些都还停留在“应用内部视角”

第一次重建关注的是：

• 页面怎么拆
• 状态怎么流动
• 模块怎么依赖

而鸿蒙真正带来的变化是：

应用不再是孤立运行的单体，而是系统级协作节点。

如果架构重建仍然围绕：

“单 App 自洽”

那么复杂度回潮只是时间问题。

第二次失控的真正源头：系统边界被打开

在传统移动端里：

App 的边界 = 进程边界

但在鸿蒙里：

• 多设备协同
• 跨应用任务流
• 原子化服务组合
• 系统级数据共享

都会让一个问题出现：

你的架构开始承担“系统职责”。

代码对比：单体思维 vs 系统节点思维

传统单 App 状态写法

// 页面内部直接持有业务状态
@State orderList: Order[] = []

async aboutToAppear() {
  this.orderList = await OrderApi.queryList()
}

问题不在代码对不对，而在于：

状态只属于这个页面。

一旦出现：

• 跨设备继续任务
• 系统恢复
• 其他应用修改订单

这个状态模型立即失效。

系统节点化的状态归属

// 任务级 Store，而不是页面级状态
class OrderTaskStore {
  private orders: Order[] = []

  async load() {
    this.orders = await OrderRepository.query()
  }

  getOrders() {
    return this.orders
  }
}

页面只订阅任务：

@State orders: Order[] = []

aboutToAppear() {
  this.orders = OrderTaskManager.current().getOrders()
}

关键变化：

状态从「页面所有」 → 变为「任务所有」

这就是系统化第一步。

一个关键误判：把“架构问题”当成“代码问题”

当复杂度再次上升时，团队常见反应是：

• 再做一次重构
• 再细化分层
• 再抽象一套基类
• 再统一一套状态框架

但现实是：

复杂度根本不在代码层。

而在三个更深的结构。

1. 任务模型没有被重建

很多鸿蒙 App 仍然是：

页面 = 业务入口
页面生命周期 = 业务生命周期

但鸿蒙更接近：

任务才是真正的业务载体。

页面驱动模型

// 每个页面自己发请求、管生命周期
aboutToAppear() {
  this.loadData()
}

任务驱动模型

class UploadTask {
  start() { /* 启动 */ }
  pause() { /* 暂停 */ }
  resume() { /* 恢复 */ }
}

页面只负责展示：

@State progress: number = 0

aboutToAppear() {
  this.progress = UploadTaskManager.current().progress()
}

页面从“控制者”降级为“观察者”。

复杂度立刻下降一个维度。

2. 状态边界没有系统化

第一次重建通常只解决：

• UI 状态
• 页面状态
• 模块状态

但鸿蒙真正困难的是：

• 跨设备状态
• 跨任务状态
• 系统恢复状态
• 分布式同步状态

错误示例：状态散落

globalThis.userInfo = user

@State cartCount = LocalStorage.get('cart')

看似方便，实际意味着：

状态没有归属权。

正确方向：状态分层归属

class SessionStore {}      // 登录态
class TaskStore {}         // 任务态
class DeviceStore {}       // 设备协同态
class UIStore {}           // 纯界面态

先分清“谁拥有状态”，再谈状态管理框架。

3. 协作模型仍是单机思维

很多项目虽然运行在鸿蒙上，但架构仍是：

单机应用 + 分布式补丁

典型代码味道：

if (isDistributed) {
  syncData()
}

这说明：

分布式只是 feature，不是基础模型。

真正的协作起点

interface Task {
  id: string
  deviceId: string
  state: 'running' | 'paused'
}

TaskScheduler.dispatch(task)

先有“可调度任务”， 才有“多设备协同”。

顺序一旦反了，架构一定再次失控。

为什么第二次失控往往更致命

第一次混乱时，团队通常还有：

• 重构信心
• 架构热情
• 时间窗口

但第二次复杂度回潮时：

1. 业务已经很重

2. 架构信任开始下降

团队会出现一种声音：

“别再重构了，上次也没解决问题。”

这是最危险的阶段。

因为这意味着：

系统将进入长期失控，而不是短期混乱。

真正的分水岭：从“应用架构”走向“系统架构”

要阻止第二次失控，唯一的方法不是：

再做一次代码级重建

而是完成一次更深的跃迁：

从这里：

设计一个结构清晰的 App

走向这里：

设计一个可参与系统协作的节点

总结

很多鸿蒙项目并不是死在：

• 技术难度
• 分布式能力
• 性能瓶颈

而是死在：

第二次复杂度回潮之后，团队失去了再次进化的能力。

第一次重建是技术问题。
第二次失控，是认知问题。