鸿蒙 App 架构重建后，为何再次失控

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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- 第一次架构重建，本质上只修复了表面
- - 这些都还停留在"应用内部视角"
- 第二次失控的真正源头：系统边界被打开
- [代码对比：单体思维 vs 系统节点思维](#代码对比：单体思维 vs 系统节点思维)
- - [传统单 App 状态写法](#传统单 App 状态写法)
  - 系统节点化的状态归属
- 一个关键误判：把"架构问题"当成"代码问题"
- - [1. 任务模型没有被重建](#1. 任务模型没有被重建)
  - - 页面驱动模型
    - 任务驱动模型
  - [2. 状态边界没有系统化](#2. 状态边界没有系统化)
  - - 错误示例：状态散落
    - 正确方向：状态分层归属
  - [3. 协作模型仍是单机思维](#3. 协作模型仍是单机思维)
  - 真正的协作起点
- 为什么第二次失控往往更致命
- - 第一次混乱时，团队通常还有：
  - 但第二次复杂度回潮时：
  - - [1. 业务已经很重](#1. 业务已经很重)
    - [2. 架构信任开始下降](#2. 架构信任开始下降)
- 真正的分水岭：从"应用架构"走向"系统架构"
- - 从这里：
  - 走向这里：
- 总结

引言

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

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

很多人会困惑：

我们不是已经做过一次"正确的架构重建"了吗？

为什么复杂度还是回来了？

真正的答案其实很残酷：

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

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

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

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

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

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

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

第一次重建关注的是：

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

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

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

如果架构重建仍然围绕：

"单 App 自洽"

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

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

在传统移动端里：

App 的边界 = 进程边界

但在鸿蒙里：

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

都会让一个问题出现：

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

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

传统单 App 状态写法

ts 复制代码

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

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

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

状态只属于这个页面。

一旦出现：

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

这个状态模型立即失效。

系统节点化的状态归属

ts 复制代码

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

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

  getOrders() {
    return this.orders
  }
}

页面只订阅任务：

ts 复制代码

@State orders: Order[] = []

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

关键变化：

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

这就是系统化第一步。

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

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

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

但现实是：

复杂度根本不在代码层。

而在三个更深的结构。

1. 任务模型没有被重建

很多鸿蒙 App 仍然是：

页面 = 业务入口

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

但鸿蒙更接近：

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

页面驱动模型

ts 复制代码

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

任务驱动模型

ts 复制代码

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

页面只负责展示：

ts 复制代码

@State progress: number = 0

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

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

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

2. 状态边界没有系统化

第一次重建通常只解决：

UI 状态
页面状态
模块状态

但鸿蒙真正困难的是：

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

错误示例：状态散落

ts 复制代码

globalThis.userInfo = user

ts 复制代码

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

看似方便，实际意味着：

状态没有归属权。

正确方向：状态分层归属

ts 复制代码

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

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

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

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

单机应用 + 分布式补丁

典型代码味道：

ts 复制代码

if (isDistributed) {
  syncData()
}

这说明：

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

真正的协作起点

ts 复制代码

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

ts 复制代码

TaskScheduler.dispatch(task)

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

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

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

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

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

但第二次复杂度回潮时：

1. 业务已经很重

2. 架构信任开始下降

团队会出现一种声音：

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

这是最危险的阶段。

因为这意味着：

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

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

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

再做一次代码级重建

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

从这里：

设计一个结构清晰的 App

走向这里：

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

总结

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

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

而是死在：

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

第一次重建是技术问题。

第二次失控，是认知问题。