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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、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
@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、业务、数据三者一定要分离。

这样项目才会：

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