子玥酱
（掘金 / 知乎 / 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、组件系统设计
把这三件事做好，项目规模变大时，架构会稳定很多。
