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

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

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

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

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

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

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

引言

很多开发者在做鸿蒙应用时，一开始项目都很简单。可能只有几个页面：

Login
Home
Profile

代码结构也很直观：

pages
components
utils

项目可以快速跑起来，功能也很快能完成。但当项目逐渐变大，功能越来越多时，很多团队都会遇到一个问题：

代码越来越乱。

很多时候大家会以为是：

• 代码写得不好
• 项目复杂度太高

但真正的问题往往只有一个：

没有真正的依赖管理。

一、很多项目只有“文件夹结构”

很多项目看起来结构很清晰：

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

但仔细看代码会发现：

pages → services
services → pages
components → services
services → components

依赖关系其实是：

所有模块互相引用

结构虽然看起来是分层的，但实际上 完全没有依赖规则。换句话说：

只是把代码放进不同文件夹而已。

这不叫架构。

二、典型的依赖混乱案例

很多鸿蒙项目很容易变成这样：

HomePage
 ├─ 调用 UserService
 ├─ 调用 OrderService
 └─ 调用 PaymentService

然后：

OrderService
 └─ 调用 UserService

接着：

UserService
 └─ 调用 OrderService

于是依赖变成：

UserService ↔ OrderService

循环依赖出现，一旦发生这种情况：

• 重构困难
• 模块无法拆分
• 修改风险极高

三、组件也开始写业务逻辑

很多项目还会出现另一种问题：组件直接依赖 Service。 例如：

@Component
struct UserCard {

  async loadUser() {
    let service = new UserService()
    this.user = await service.getUser()
  }

}

这样组件就变成：

UI + 业务逻辑

组件本来应该是：

可复用 UI

结果却变成：

业务组件

复用性直接消失。

四、页面变成“超级控制器”

如果依赖关系没有控制，页面通常会变成这样：

HomePage
 ├─ 用户信息
 ├─ 推荐内容
 ├─ 广告
 ├─ 订单状态
 └─ 活动信息

代码可能会长这样：

aboutToAppear() {
  this.loadUser()
  this.loadOrders()
  this.loadAds()
  this.loadRecommend()
}

页面逐渐变成：

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

最后文件可能变成：

HomePage.ets
2000 行

这就是典型的 巨型页面文件。

五、真正的依赖管理是什么

真正的依赖管理，其实只有一个核心原则：

依赖必须单向流动。

推荐结构：

Page
 ↓
Service
 ↓
Repository
 ↓
Network

也就是说：

UI → 业务 → 数据 → 网络

绝对不能出现：

Network → Page

或者：

Service → Page

六、正确的模块职责

如果依赖关系设计正确，每一层职责非常清晰。

Page

只负责 UI，例如：

@Entry
@Component
struct UserPage {

  service: UserService = new UserService()

  async loadUser() {
    const user = await this.service.getUser()
    this.name = user.name
  }

}

Service

负责业务逻辑。

export class UserService {

  repo: UserRepository = new UserRepository()

  async getUser() {
    return await this.repo.fetchUser()
  }

}

Repository

负责数据来源。

export class UserRepository {

  client: HttpClient = new HttpClient()

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

}

Network

负责网络请求。

export class HttpClient {

  async get(url: string) {
    ...
  }

}

依赖关系变成：

Page → Service → Repository → Network

非常清晰。

七、组件应该保持“无业务”

组件只负责 UI，例如：

@Component
export struct UserCard {

  @Prop name: string

  build() {
    Text(this.name)
  }

}

组件不应该：

调用 API
操作 Service
处理业务

否则组件就无法复用。

八、依赖失控的典型信号

如果项目出现以下情况，大概率依赖管理已经失控：

1、页面文件超过 1500 行

说明：

UI + 业务逻辑混在一起

2、Service 互相调用

例如：

UserService → OrderService
OrderService → UserService

3、组件调用 API

说明 UI 和业务没有分离。

4、修改一个模块影响很多地方

说明模块耦合严重。

总结

很多鸿蒙 App 项目虽然有目录结构：

pages
services
components

但实际上：

只是文件分类，并没有真正的依赖管理。

真正的依赖管理需要遵循一个原则：

依赖单向流动

推荐结构：

Page → Service → Repository → Network

同时保持：

Component → 纯 UI
Service → 业务逻辑
Repository → 数据来源

只要依赖关系设计正确，项目会有几个明显变化：

• 页面代码更简单
• 模块更容易复用
• 项目更容易维护

简单来说就是一句话：

架构不是目录结构，而是依赖关系。