鸿蒙 App 的代码结构应该怎么拆分

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

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

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

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

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

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

引言

很多人刚开始写鸿蒙应用时，项目结构往往很简单：

entry ├─ pages ├─ components └─ utils

一开始写 Demo 或小项目，这样完全没问题。但只要项目稍微复杂一点，很快就会遇到几个问题：

• 页面代码越来越长
• 业务逻辑和 UI 混在一起
• 网络请求到处都是
• 很难维护

很多人最后会发现：

项目不是功能难，而是代码结构乱。

所以问题就来了：鸿蒙 App 的代码结构到底应该怎么拆？

一、最常见的错误结构

很多初学项目会长这样：

entry ├─ pages │ ├─ Home.ets │ ├─ Login.ets │ └─ Profile.ets │ ├─ components │ └─ utils

问题在哪？

1、UI 和业务逻辑混在一起

例如一个页面：

@Entry@Componentstruct HomePage{@Statelist:string[]=[]aboutToAppear(){this.loadData()}asyncloadData(){constresult=awaitfetch("https://api.example.com/list")constdata=awaitresult.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

代码：

importhttpfrom'@ohos.net.http'exportclassUserService{asyncgetUserList(){constrequest=http.createHttp()constresponse=awaitrequest.request("https://api.example.com/users",{method:http.RequestMethod.GET})returnJSON.parse(response.result)}}

四、页面只负责 UI

页面只负责展示数据，例如：

import{UserService}from'../services/UserService'@Entry@Componentstruct UserPage{@Stateusers: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:numbername:stringavatar:string}

Service 中使用：

import{User}from'../models/UserModel'asyncgetUserList():Promise<User[]>{...}

这样有几个好处：

• 类型清晰
• 数据结构统一
• 方便维护

六、组件拆分

页面里的 UI 组件也应该拆分，例如：

components └─ UserItem.ets

代码：

@Componentexportstruct UserItem{@Propuser: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、业务、数据三者一定要分离。

这样项目才会：

• 好维护
• 好扩展
• 不容易变成“巨型页面文件”。