前言很多开发者刚开始学习 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使用LazyForEachLazyForEach(...)避免一次性渲染大量数据。图片懒加载不要全部本地资源。推荐OSS CDN 对象存储降低安装包体积。页面退出释放资源aboutToDisappear() { }及时释放定时器Web组件视频播放器防止内存泄漏。多人协作经验建议制定Git提交规范分支管理规范接口文档规范代码Review制度例如feature/login feature/order feature/user避免多人开发冲突。总结很多开发者认为“项目能跑就行。”但企业开发更关注可维护性可扩展性团队协作效率一个好的 HarmonyOS NEXT 项目架构能够让项目从10个页面扩展到100个页面时依然保持清晰稳定。真正优秀的开发者不是写得快而是能够让代码在半年后依然容易维护。架构决定项目上限规范决定团队效率。
HarmonyOS NEXT项目实战：从0到1搭建企业级项目架构
前言很多开发者刚开始学习 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使用LazyForEachLazyForEach(...)避免一次性渲染大量数据。图片懒加载不要全部本地资源。推荐OSS CDN 对象存储降低安装包体积。页面退出释放资源aboutToDisappear() { }及时释放定时器Web组件视频播放器防止内存泄漏。多人协作经验建议制定Git提交规范分支管理规范接口文档规范代码Review制度例如feature/login feature/order feature/user避免多人开发冲突。总结很多开发者认为“项目能跑就行。”但企业开发更关注可维护性可扩展性团队协作效率一个好的 HarmonyOS NEXT 项目架构能够让项目从10个页面扩展到100个页面时依然保持清晰稳定。真正优秀的开发者不是写得快而是能够让代码在半年后依然容易维护。架构决定项目上限规范决定团队效率。
