子玥酱
（掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案， 在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化 内容平台：掘金、知乎、CSDN、简书 创作特点：实战导向、源码拆解、少空谈多落地 文章状态：长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨ 👋 如果你正在做前端，或准备长期走前端这条路 📚 关注我，第一时间获取前端行业趋势与实践总结 🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构） 💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。 愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- 一、最常见的错误结构
-
- 1、UI 和业务逻辑混在一起
- 二、推荐的基础结构
- 三、业务逻辑放到 Service 层
- 四、页面只负责 UI
- 五、数据模型单独管理
- 六、组件拆分
- 七、大型项目结构
- 八、AI 应用的结构变化
- 九、代码结构设计的核心原则
-
- 1、UI 和业务分离
- 2、数据模型统一
- 3、组件复用
- 4、模块化拆分
- 总结
引言
很多人刚开始写鸿蒙应用时，项目结构往往很简单：
entry
├─ pages
├─ components
└─ utils
一开始写 Demo 或小项目，这样完全没问题。但只要项目稍微复杂一点，很快就会遇到几个问题：
- 页面代码越来越长
- 业务逻辑和 UI 混在一起
- 网络请求到处都是
- 很难维护
很多人最后会发现：
项目不是功能难，而是代码结构乱。
所以问题就来了：鸿蒙 App 的代码结构到底应该怎么拆？
一、最常见的错误结构
很多初学项目会长这样：
entry
├─ pages
│ ├─ Home.ets
│ ├─ Login.ets
│ └─ Profile.ets
│
├─ components
│
└─ utils
问题在哪？
1、UI 和业务逻辑混在一起
例如一个页面：
@Entry
@Component
struct HomePage {
@State list: string[] = []
aboutToAppear() {
this.loadData()
}
async loadData() {
const result = await fetch("https://api.example.com/list")
const data = await result.json()
this.list = data
}
build() {
Column() {
ForEach(this.list, (item: string) => {
Text(item)
})
}
}
}
这里的问题是：
- UI
- 网络请求
- 数据解析
全部在一个文件，当页面越来越复杂时，就会变得难以维护。
二、推荐的基础结构
比较推荐的结构是 分层设计：
entry
├─ pages
├─ components
├─ services
├─ models
└─ utils
含义分别是：
pages 页面
components UI组件
services 业务服务
models 数据模型
utils 工具函数
三、业务逻辑放到 Service 层
网络请求、业务逻辑不应该写在页面里，而是放到 Service 层，例如：
services
└─ UserService.ets
代码：
import http from '@ohos.net.http'
export class UserService {
async getUserList() {
const request = http.createHttp()
const response = await request.request(
"https://api.example.com/users",
{
method: http.RequestMethod.GET
}
)
return JSON.parse(response.result)
}
}
四、页面只负责 UI
页面只负责 展示数据，例如：
import { UserService } from '../services/UserService'
@Entry
@Component
struct UserPage {
@State users: any[] = []
userService: UserService = new UserService()
aboutToAppear() {
this.loadUsers()
}
async loadUsers() {
this.users = await this.userService.getUserList()
}
build() {
Column() {
ForEach(this.users, (user) => {
Text(user.name)
})
}
}
}
这样代码职责就清晰了：
Page → UI
Service → 业务逻辑
五、数据模型单独管理
如果项目稍微大一点，建议把数据结构单独管理，例如：
models
└─ UserModel.ets
代码：
export interface User {
id: number
name: string
avatar: string
}
Service 中使用：
import { User } from '../models/UserModel'
async getUserList(): Promise<User[]> {
…
}
这样有几个好处：
- 类型清晰
- 数据结构统一
- 方便维护
六、组件拆分
页面里的 UI 组件也应该拆分，例如：
components
└─ UserItem.ets
代码：
@Component
export struct UserItem {
@Prop user: any
build() {
Row() {
Image(this.user.avatar)
.width(40)
.height(40)
Text(this.user.name)
}
}
}
页面使用：
ForEach(this.users, (user) => {
UserItem({ user: user })
})
这样页面会非常干净。
七、大型项目结构
如果是大型项目，结构通常会进一步细化，例如：
entry
├─ pages
│ ├─ home
│ ├─ profile
│ └─ login
│
├─ components
│
├─ services
│ ├─ user
│ ├─ order
│ └─ payment
│
├─ models
│
├─ store
│
└─ utils
含义：
services 按业务拆分
pages 按模块拆分
store 状态管理
八、AI 应用的结构变化
如果是 AI 应用，结构通常还会增加 AI 层，例如：
entry
├─ pages
├─ components
├─ services
├─ ai
│ ├─ ai_service
│ ├─ ai_router
│ └─ prompt_manager
│
├─ models
└─ utils
例如，AI Service：
export class AIService {
async chat(message: string) {
return await this.requestModel(message)
}
async requestModel(message: string) {
// 调用 AI API
}
}
这样 AI 能力也变成独立模块。
九、代码结构设计的核心原则
总结一下，一个好的鸿蒙 App 代码结构通常遵循几个原则：
1、UI 和业务分离
Page → UI
Service → 业务
2、数据模型统一
Model → 数据结构
3、组件复用
Component → UI复用
4、模块化拆分
按业务模块拆分
总结
鸿蒙 App 的代码结构，本质上和很多现代应用架构类似。推荐结构：
entry
├─ pages
├─ components
├─ services
├─ models
└─ utils
如果项目变大，可以进一步拆分：
modules
services
ai
store
核心原则其实只有一句话：
UI、业务、数据三者一定要分离。
这样项目才会：
- 好维护
- 好扩展
- 不容易变成“巨型页面文件”。
