前言
很多开发者刚开始学习 HarmonyOS NEXT 时，往往关注的是页面开发、组件使用和API调用。
但真正进入企业项目后会发现：
-
页面开发只占20%
-
架构设计占30%
-
工程化建设占50%
一个优秀的项目架构不仅能够提高开发效率，还能降低后期维护成本。
本文将结合实际开发经验，分享一套适用于 HarmonyOS NEXT 的企业级项目架构方案。
为什么要重视项目架构？
很多新手项目目录是这样的：
src
├── pages
│ ├── Home
│ ├── User
│ ├── Order
│ └── Goods开发初期没问题。
当项目达到：
-
50+页面
-
100+接口
-
多人协作
就会出现：
-
文件难找
-
命名混乱
-
代码重复
-
维护困难
因此必须提前规划项目结构。
推荐项目目录
src
│
├── pages 页面
├── components 公共组件
├── api 接口层
├── model 数据模型
├── utils 工具类
├── constants 常量
├── router 路由管理
├── hooks 自定义Hook
├── store 状态管理
├── services 业务服务层
├── common 公共配置
└── resources 资源文件这样的结构能够满足大部分企业项目需求。
第一层：页面层（Pages）
职责：
-
页面展示
-
用户交互
-
数据绑定
不要把业务逻辑全部写在页面中。
错误示例：
loadData() {
axios.get(...)
...
}推荐：
loadData() {
userService.getUserInfo()
}页面只负责展示。
第二层：接口层（API）
统一管理网络请求。
目录：
api
├── userApi.ts
├── orderApi.ts
├── goodsApi.ts示例：
export function getUserInfo() {
return request({
url:'/user/info',
method:'GET'
})
}优点：
-
接口集中管理
-
修改方便
-
统一维护
第三层：业务层（Service）
很多项目直接：
Page -> Api推荐：
Page -> Service -> Api例如：
class UserService {
async getProfile() {
const user = await getUserInfo()
return {
name:user.name,
vip:user.vip
}
}
}这样业务逻辑与页面彻底解耦。
第四层：公共组件
推荐建立：
components
├── CommonButton
├── CommonDialog
├── CommonLoading
├── CommonCard
├── EmptyView原则：
出现两次以上就考虑抽组件。
不要复制粘贴。
第五层：工具类封装
目录：
utils常见工具：
DateUtil
StorageUtil
PermissionUtil
ToastUtil
LogUtil
EncryptUtil例如：
ToastUtil.show("保存成功")比直接调用系统API更方便。
路由统一管理
不要满项目写：
router.pushUrl(...)建立：
export const RouterPath = {
HOME:'pages/Home',
USER:'pages/User',
ORDER:'pages/Order'
}跳转：
router.pushUrl({
url:RouterPath.USER
})优点：
-
防止写错路径
-
支持统一维护
网络请求统一封装
企业项目必做。
创建：
network
├── request.ts
├── interceptor.ts统一处理：
-
Token
-
请求头
-
错误码
-
登录失效
-
Loading
页面无需重复编写。
状态管理方案
小型项目：
@State中型项目：
@Provide
@Consume大型项目：
Store管理：
-
用户信息
-
登录状态
-
主题配置
-
全局设置
避免层层传参。
企业项目开发规范
命名规范
组件：
UserCard
GoodsItem
OrderList变量：
userInfo
goodsList
orderCount常量：
const MAX_COUNT = 100统一风格非常重要。
性能优化建议
List使用LazyForEach
LazyForEach(...)避免一次性渲染大量数据。
图片懒加载
不要全部本地资源。
推荐：
OSS
CDN
对象存储降低安装包体积。
页面退出释放资源
aboutToDisappear() {
}及时释放：
-
定时器
-
Web组件
-
视频播放器
防止内存泄漏。
多人协作经验
建议制定：
-
Git提交规范
-
分支管理规范
-
接口文档规范
-
代码Review制度
例如：
feature/login
feature/order
feature/user避免多人开发冲突。
总结
很多开发者认为：
"项目能跑就行。"
但企业开发更关注：
-
可维护性
-
可扩展性
-
团队协作效率
一个好的 HarmonyOS NEXT 项目架构，能够让项目从10个页面扩展到100个页面时依然保持清晰稳定。
真正优秀的开发者，不是写得快，而是能够让代码在半年后依然容易维护。
架构决定项目上限，规范决定团队效率。