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

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

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

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

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

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

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

引言

很多开发者刚开始做 HarmonyOS 应用 时，项目规模通常不大：

• 几个页面
• 几个组件
• 一个简单的数据结构

代码结构可能是这样的：

pages
components
utils

一开始看起来完全没问题。

但当项目逐渐变大：

• 页面数量增加
• 业务逻辑复杂
• 团队成员变多

原来的结构很快就会出现问题：

• 代码越来越难维护
• 状态管理混乱
• 页面之间耦合严重

我在做一个鸿蒙项目时，从 小型项目结构一路演进到大型应用架构，中间经历了几次比较典型的架构变化。

阶段一：小项目结构

很多鸿蒙项目一开始都是这种结构：

pages
 ├─ HomePage
 ├─ DetailPage
 ├─ ProfilePage

components
 ├─ Banner
 ├─ Card

utils
 ├─ request
 ├─ storage

例如一个页面：

@Entry
@Component
struct HomePage {

  @State list: string[] = []

  aboutToAppear() {
    this.loadData()
  }

  async loadData() {
    this.list = await request('/api/list')
  }

  build() {
    List() {
      LazyForEach(this.list, (item) => {
        ListItem() {
          Text(item)
        }
      })
    }
  }
}

这种结构适合：

• Demo
• 小项目
• 个人练手项目

但随着页面越来越多，会出现几个问题：

• 页面逻辑越来越重
• 网络请求散落在各个页面
• 状态难以复用

阶段二：业务模块化

当页面超过 20 个以上，很多团队会开始进行第一次架构调整。

从 页面驱动 变成 业务模块驱动。

结构变成这样：

features
 ├─ home
 │   ├─ HomePage
 │   ├─ HomeService
 │   └─ components
 │
 ├─ user
 │   ├─ ProfilePage
 │   ├─ UserService
 │   └─ components
 │
 ├─ order
 │   ├─ OrderPage
 │   ├─ OrderService
 │   └─ components

common
 ├─ components
 ├─ utils
 └─ request

这种结构有一个明显好处：

业务逻辑聚合在一起。

例如：

home
 ├─ 页面
 ├─ 组件
 ├─ API

Home 模块相关代码全部在同一目录。

例如：

class HomeService {

  async fetchFeed() {
    return request('/api/feed')
  }

}

页面调用：

aboutToAppear() {
  new HomeService().fetchFeed().then(res => {
    this.list = res
  })
}

这样结构会清晰很多。

阶段三：状态管理层出现

当项目继续变大，你会发现新的问题：

• 页面之间需要共享数据
• 用户信息到处传
• 状态同步困难

例如：

用户信息
登录状态
购物车数据

如果全部用 @Prop 或 @Link 传递，会非常混乱。这时候通常会引入 全局状态层。

鸿蒙中常见方式：

@Provide / @Consume

例如在根组件：

@Provide userInfo: User = {
  name: "Tom"
}

子组件：

@Consume userInfo: User

这样可以避免：

层层传参

很多大型应用还会做 Store 层：

store
 ├─ userStore
 ├─ cartStore
 └─ appStore

例如：

class UserStore {
  @State userInfo: User | null = null

  login(user: User) {
    this.userInfo = user
  }
}

这样状态管理就会更清晰。

阶段四：分层架构

当应用规模继续扩大时，仅仅模块化还不够。很多团队会引入 分层架构。

典型结构是：

presentation
service
repository
model

例如：

features
 └─ order
     ├─ pages
     ├─ components
     ├─ service
     ├─ repository
     └─ model

各层职责：

presentation（UI层）

页面
组件

service（业务逻辑层）

订单逻辑
状态处理

repository（数据层）

网络请求
本地缓存
数据库

例如：

class OrderRepository {

  async fetchOrders() {
    return request('/api/orders')
  }

}

Service：

class OrderService {

  repository = new OrderRepository()

  async getOrders() {
    return this.repository.fetchOrders()
  }

}

Page：

aboutToAppear() {
  new OrderService().getOrders().then(res => {
    this.list = res
  })
}

这样 UI 就不会直接依赖 API。

阶段五：组件系统化

当项目规模到 几十个页面 时，组件数量会暴涨。很多团队会建立 组件系统。

例如：

design-system
 ├─ Button
 ├─ Card
 ├─ Modal
 ├─ Form
 └─ Table

统一设计：

• UI 风格
• 交互逻辑
• 主题

例如：

@Component
struct AppButton {

  @Prop text: string

  build() {
    Button(this.text)
      .width(200)
      .height(44)
  }
}

所有页面统一使用：

AppButton

而不是：

Button

这样：

• UI 一致
• 维护更容易

总结

从小项目到大型鸿蒙应用，架构通常会经历这样一个演进过程：

页面驱动
↓
业务模块化
↓
状态管理层
↓
分层架构
↓
组件系统

很多项目的问题其实不是 技术选型错误，而是：

架构没有随着项目规模演进。

小项目结构用在大项目上，迟早会失控。如果你准备做一个长期维护的鸿蒙应用，建议尽早规划三件事：

1、业务模块划分
2、状态管理方案
3、组件系统设计

把这三件事做好，项目规模变大时，架构会稳定很多。