子玥酱
（掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案， 在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化 内容平台：掘金、知乎、CSDN、简书 创作特点：实战导向、源码拆解、少空谈多落地 文章状态：长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨ 👋 如果你正在做前端，或准备长期走前端这条路 📚 关注我，第一时间获取前端行业趋势与实践总结 🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构） 💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。 愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- 一、一个完整项目结构示例
- 二、Pages：页面层
- 三、Components：可复用组件
- 四、Services：业务逻辑层
- 五、Models：数据模型
- 六、Store：状态管理
- 七、Utils：工具函数
- 八、Config：配置管理
- 九、如果项目加入 AI 功能
- 十、一个更完整的企业级结构
- 总结
引言
很多人刚开始写鸿蒙应用时，项目结构通常很简单：
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，业务逻辑全部下沉。
项目就不会轻易失控。
