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

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

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

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

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

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

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

引言

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

entry
 ├─ pages
 ├─ components
 └─ utils

这种结构在 Demo 项目里完全没问题，但只要项目稍微复杂一点，比如：

• 登录系统
• 用户中心
• 网络请求
• 数据缓存
• AI 功能

代码很快就会变得混乱，很多开发者做到中期会发现一个问题：

项目越来越难维护，找代码越来越困难。

所以问题就变成：一个真实的鸿蒙 App，工程目录到底应该怎么设计？

一、一个完整项目结构示例

一个中大型鸿蒙应用，目录大概会长这样：

entry
 ├─ pages
 │   ├─ home
 │   │   └─ HomePage.ets
 │   │
 │   ├─ login
 │   │   └─ LoginPage.ets
 │   │
 │   └─ profile
 │       └─ ProfilePage.ets
 │
 ├─ components
 │   ├─ common
 │   │   ├─ LoadingView.ets
 │   │   └─ EmptyView.ets
 │   │
 │   └─ user
 │       └─ UserCard.ets
 │
 ├─ services
 │   ├─ user
 │   │   └─ UserService.ets
 │   │
 │   ├─ auth
 │   │   └─ AuthService.ets
 │   │
 │   └─ network
 │       └─ HttpClient.ets
 │
 ├─ models
 │   ├─ UserModel.ets
 │   └─ ApiResponse.ets
 │
 ├─ store
 │   └─ UserStore.ets
 │
 ├─ utils
 │   ├─ Logger.ets
 │   └─ DateUtil.ets
 │
 └─ config
     └─ AppConfig.ets

这个结构基本已经可以支撑：

• 中型 App
• 多模块业务
• AI 功能扩展

二、Pages：页面层

pages 目录只存放 页面 UI。例如：

pages
 ├─ home
 ├─ login
 └─ profile

页面示例：

@Entry
@Component
struct HomePage {

  @State userName: string = ""

  aboutToAppear() {
    this.loadUser()
  }

  async loadUser() {
    let service = new UserService()
    let user = await service.getUserInfo()
    this.userName = user.name
  }

  build() {
    Column() {
      Text("欢迎")
      Text(this.userName)
    }
  }
}

页面只做三件事：

展示 UI
接收用户操作
调用 Service

不要写复杂逻辑。

三、Components：可复用组件

components 目录存放 通用 UI 组件。例如：

components
 ├─ common
 └─ user

组件示例：

UserCard.ets

代码：

@Component
export struct UserCard {

  @Prop name: string
  @Prop avatar: string

  build() {
    Row() {
      Image(this.avatar)
        .width(40)
        .height(40)

      Text(this.name)
        .margin({ left: 10 })
    }
  }
}

页面使用：

UserCard({
  name: user.name,
  avatar: user.avatar
})

这样组件可以在多个页面复用。

四、Services：业务逻辑层

Service 层负责：

• 网络请求
• 业务逻辑
• 数据处理

例如：

services
 ├─ user
 ├─ auth
 └─ network

网络层：

HttpClient.ets

代码：

import http from '@ohos.net.http'

export class HttpClient {

  async get(url: string) {
    const request = http.createHttp()

    const response = await request.request(url, {
      method: http.RequestMethod.GET
    })

    return JSON.parse(response.result)
  }

}

UserService：

export class UserService {

  client: HttpClient = new HttpClient()

  async getUserInfo() {
    return await this.client.get("/api/user")
  }

}

这样所有 API 调用都会集中管理。

五、Models：数据模型

models 目录存放 数据结构定义。例如：

UserModel.ets

代码：

export interface User {

  id: number
  name: string
  avatar: string

}

这样数据结构统一管理。

Service：

async getUserInfo(): Promise<User> {
  ...
}

六、Store：状态管理

如果 App 有全局状态，可以使用 store 管理。例如：

store
 └─ UserStore.ets

代码：

export class UserStore {

  static currentUser: User | null = null

  static setUser(user: User) {
    this.currentUser = user
  }

}

页面：

UserStore.setUser(user)

七、Utils：工具函数

utils 存放通用工具。例如：

utils
 ├─ Logger
 └─ DateUtil

示例：

export class Logger {

  static log(message: string) {
    console.info("[APP]", message)
  }

}

八、Config：配置管理

config 目录用于管理：

• API 地址
• 环境变量
• 应用配置

例如：

AppConfig.ets

代码：

export const AppConfig = {

  API_BASE_URL: "https://api.example.com",

  VERSION: "1.0.0"

}

九、如果项目加入 AI 功能

AI 应用通常会增加一个模块：

ai

结构：

ai
 ├─ ai_service
 ├─ ai_router
 └─ prompt_manager

例如：

AIService.ets

代码：

export class AIService {

  async chat(prompt: string) {
    return await this.requestAI(prompt)
  }

  async requestAI(prompt: string) {
    // 调用 AI API
  }

}

这样 AI 功能就不会污染普通业务代码。

十、一个更完整的企业级结构

如果是更大的项目，结构可能会变成：

entry
 ├─ pages
 ├─ components
 ├─ modules
 │   ├─ user
 │   ├─ order
 │   └─ payment
 │
 ├─ services
 ├─ models
 ├─ ai
 ├─ store
 ├─ utils
 └─ config

这种结构基本可以支持：

• 大型业务
• AI 应用
• 多团队开发

总结

一个真实鸿蒙 App 的推荐工程结构：

entry
 ├─ pages
 ├─ components
 ├─ services
 ├─ models
 ├─ store
 ├─ utils
 └─ config

如果是 AI 应用，建议再增加：

ai

核心思想其实很简单：

UI → pages
组件 → components
业务 → services
数据 → models
状态 → store
工具 → utils
配置 → config

只要遵守一个原则：

页面只写 UI，业务逻辑全部下沉。

项目就不会轻易失控。