文章目录前言hvigor 是什么代码实现模块类型HAP / HAR / HSP新建一个 HAR 库模块核心代码完整示例主模块引用库代码解析实现拆解多模块构建配置代码清单拆分的经验法则常见误区小白必踩完整可运行示例hvigor 多模块配置关键代码写在最后前言项目小的时候所有代码塞一个entry模块没问题。但等项目变大、多人协作、要复用组件库就必须做模块化拆分。HarmonyOS 用hvigor基于 TS 的构建工具类似前端的 Gradle/Webpack管理构建和模块。这篇文章讲清hvigor 是干嘛的、模块怎么拆HAR/HSP、多模块工程怎么配置。hvigor 是什么hvigor是鸿蒙的构建引擎负责把你的 ArkTS 代码编译、打包成 app。你平时点 DevEco 的运行按钮背后就是它在干活。工程根目录的关键文件代码实现project/ ├── build-profile.json5 # 工程级构建配置签名、设备类型 ├── hvigorfile.ts # 根构建脚本 ├── entry/ # 主模块 │ └── hvigorfile.ts └── library/ # 共享库模块 └── hvigorfile.ts每个模块都有自己的hvigorfile.ts决定它是应用模块还是库模块。模块类型HAP / HAR / HSP类型全称用途HAPHarmonyOS Ability Package可独立运行的业务模块如 entryHARHarmonyOS Ability Resource静态共享库编译时拷贝进引用方HSPHarmonyOS Shared Package动态共享包运行时共享记忆法HAP 是能跑的 app 模块HAR 是打包时复制的库每个引用方都留一份HSP 是运行时共享的库多模块共用一份省包体。新建一个 HAR 库模块把通用组件、工具函数抽到 HAR供多个业务模块复用核心代码// library/index.ets 导出的公共能力exportclassDateUtil{staticformat(ts:number):string{returnnewDate(ts).toLocaleString()}}exportconstCOLORS{primary:#4A90E2}在library/hvigorfile.ts里声明它是 HAR完整示例import{harTasks}fromohos/hvigor-ohos-pluginexportdefault{system:harTasks,// 标记为 HAR 库plugins:[]}主模块引用库在entry/oh-package.json5里依赖这个库代码解析{ dependencies: { mylibrary: file:../library } }然后代码里直接 import 用实现拆解import{DateUtil,COLORS}frommylibraryText(DateUtil.format(Date.now())).fontColor(COLORS.primary)多模块构建配置build-profile.json5里声明产品形态和签名代码清单{ modules: [ { name: entry, srcPath: ./entry, targets: [{ name: default }] }, { name: library, srcPath: ./library } ], app: { signingConfigs: [{ name: default, material: { /* 签名文件 */ } }], products: [{ name: default, signingConfig: default }] } }拆分的经验法则通用 UI 组件、工具类 → 抽HAR如uicomponents、utils。多个 HAP 都要用的大块功能如分享、登录→ 抽HSP省包体。业务逻辑独立、可单独上架 → 抽HAPfeature 模块。模块之间禁止循环依赖A 依赖 BB 不能又依赖 A。常见误区小白必踩误区说明模块循环依赖A 依赖 B、B 又依赖 A编译直接死循环画依赖图避免。HAR/HSP 选错小轻通用件用 HAR重大块共用件用 HSP 省包体别乱用。通用件不抽库CommonButton复制了三遍还不抽维护噩梦。下面这段代码可以直接复制到 DevEco Studio 里运行。建议你边读边敲改一改文末「动手改一改」里的参数亲眼看看效果。完整可运行示例hvigor 多模块配置在build-profile.json5里拆出独立feature模块。关键代码// build-profile.json5节选 { modules: [ { name: entry, srcPath: ./entry, targets: [{ name: default }] }, { name: feature_home, srcPath: ./feature_home, targets: [{ name: default }] } ] }你会看到什么entry是主模块feature_home是独立业务模块。编译后各模块可单独构建、按需加载大项目协作不再互相阻塞。动手改一改新建feature_cart模块并在modules注册体验增量编译。在oh-package.json5里把公共库抽成 HAR 依赖。用hvigorw assembleHap只构建指定模块看速度提升。写在最后工程化前期麻烦后期省命。模块拆分的核心判断是这段代码会不会在别处复用会就抽库HAR/HSP业务独立就拆 HAP。别等项目烂到改一处崩三处才想起重构。现在就看看你的entry里有没有明显通用的组件先抽一个 HAR 出来练手——模块化思维一旦建立后面越写越顺。