鸿蒙 App 的代码结构应该怎么拆分
子玥酱（掘金 / 知乎 / ZEEKLOG / 简书 同名）
大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、ZEEKLOG、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
引言
很多人刚开始写鸿蒙应用时，项目结构往往很简单：
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()}asyncloadData(){const result =awaitfetch("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'exportclassUserService{asyncgetUserList(){const request = http.createHttp()const response =await request.request("https://api.example.com/users",{ method: http.RequestMethod.GET})returnJSON.parse(response.result)}}四、页面只负责 UI
页面只负责 展示数据，例如：
import{ UserService }from'../services/UserService'@Entry@Component struct UserPage {@State users:any[]=[] userService: UserService =newUserService()aboutToAppear(){this.loadUsers()}asyncloadUsers(){this.users =awaitthis.userService.getUserList()}build(){Column(){ForEach(this.users,(user)=>{Text(user.name)})}}}这样代码职责就清晰了：
Page → UI Service → 业务逻辑 五、数据模型单独管理
如果项目稍微大一点，建议把数据结构单独管理，例如：
models └─ UserModel.ets 代码：
exportinterfaceUser{ id:number name:string avatar:string}Service 中使用：
import{ User }from'../models/UserModel'asyncgetUserList():Promise<User[]>{...}这样有几个好处：
- 类型清晰
- 数据结构统一
- 方便维护
六、组件拆分
页面里的 UI 组件也应该拆分，例如：
components └─ UserItem.ets 代码：
@Componentexport struct UserItem {@Prop user:anybuild(){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：
exportclassAIService{asyncchat(message:string){returnawaitthis.requestModel(message)}asyncrequestModel(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、业务、数据三者一定要分离。
这样项目才会：
- 好维护
- 好扩展
- 不容易变成“巨型页面文件”。
