![# 多模块 HAR 合并后仍提示缺依赖:DevEco Studio 26 独立 HAR 打包的四层验收
组件库把多个 HAR 合并成一个独立 HAR,本工程构建通过,交给另一个应用却提示找不到依赖。DevEco Studio 26 支持 standalone merged HAR,目标是把交付边界收拢,但模块合并、资源、Native 库和外部依赖仍需要逐层核验。构建成功只证明生产工程当前依赖图能闭合,不代表产物脱离源码仓库后可消费。
先按这张现场排查表行动
- 明确内部与外部依赖边界。
- 检查代码资源和 Native 入口。
- consumer 与生产仓库隔离。
- 清理 ohpm 与构建缓存。
- 烟测只调用公开 API。
复现与取证起点
准备 ui、data、network 三个 HAR 和一个全新 consumer 工程。记录 moduleGraph、mergedEntries、resourceEntries、nativeEntries、externalDeps、consumerLock、compileResult 和 smokeResult。删除 consumer 的本地源码路径与缓存后重新安装,确保测试的确是归档产物。
复现记录至少包含设备形态、窗口尺寸、字体或显示配置、关键状态、操作路径和截图时间。只保存一张最终截图,无法解释问题是在布局、状态恢复还是输入阶段发生。
三个判断点
模块图决定哪些内容应该进入独立产物
先列出内部模块与外部包。内部 HAR 可合并,外部依赖是否随包交付要按官方规则和产物清单确认。
这里必须同时保存输入条件、设备或窗口形态、触发动作和最终可观察状态。工具报告用于缩小范围,任务是否可完成仍由同一条用户路径的读回结果决定。
归档内容要检查代码、资源和 Native 三类入口
只看 ets 文件会漏掉资源索引和 so。建立归档 manifest,对每类关键入口做精确断言。
这里必须同时保存输入条件、设备或窗口形态、触发动作和最终可观察状态。工具报告用于缩小范围,任务是否可完成仍由同一条用户路径的读回结果决定。
消费工程必须隔离生产仓库
同工作区测试可能通过源码依赖兜底。全新目录、清空缓存、只配置公开仓库或本地产物,才是独立性证据。
这里必须同时保存输入条件、设备或窗口形态、触发动作和最终可观察状态。工具报告用于缩小范围,任务是否可完成仍由同一条用户路径的读回结果决定。
方案对比
| 方式 | 优点 | 风险 |
|---|---|---|
| 只检查生产工程构建成功 | 最快 | 容易被根依赖兜底 |
| 只解压看文件是否存在 | 可见产物 | 不能证明消费可用 |
| 模块图、归档、干净消费、入口烟测四层验收 | 交付可信 | 需要独立工程 |
我的选择:采用第三种,让产物离开源码仓库后仍能复现安装和调用。
案例一:内部 ui 和 data HAR 成功合并
consumer 只声明一个 HAR,能访问公开 API 与资源;模块私有符号不可见,说明交付边界正确。
修复后用原始条件再次执行完整任务,并保留修改前后同一节点的可见性、可操作性和状态对照。
案例二:network HAR 仍引用未声明的外部包
生产仓库因根工程已有依赖而通过,干净 consumer 失败。把外部依赖写入交付说明和 lock 校验,或按许可与规则调整打包。
第二个案例选择不同形态或不同状态,用来证明方案不是对单一截图的局部修补。
工程侧模型
typeHarAudit={modules:string[];entries:string[];consumerOk:boolean};functioncomplete(x:HarAudit){returnx.consumerOk&&x.modules.every(m=>x.entries.some(e=>e.startsWith(m+'/')))}模型只表达稳定的决策边界,界面组件、窗口事件和工具结果通过适配器接入,避免把设备差异散落在每个页面。
可独立执行的状态断言
functionaudit(modules,entries,consumer){returnconsumer&&modules.every(m=>entries.some(e=>e.indexOf(m+'/')===0))}if(!audit(['ui','data'],['ui/index.ets','data/store.ets'],true))thrownewError('HAR 完整性误判');if(audit(['ui','data'],['ui/index.ets'],true))thrownewError('缺失模块未拦截');这些断言验证纯状态、几何或边界计算,不代表 API 26 工程已经编译,也不代表真机、模拟器特定镜像或应用市场审核已经通过。
封装与复用
封装 StandaloneHarManifest,保存模块图、归档关键入口、外部依赖摘要和干净 consumer 结果,作为组件库交付附件。
复用层输出决策和证据,不强行统一所有页面视觉。每个页面仍可保留自身信息层级,但必须满足相同的任务可达性与状态连续标准。
验证边界
本文依据当前华为官方文档整理能力与约束,纯状态模型已在本机执行。当前本机 HarmonyOS SDK 为 API 24,且没有连接 HDC 设备,因此 API 26 编译、目标模拟器镜像行为、折叠真机连续性和平台审核结果仍属于待验证项。完成目标环境验证后,应把版本、设备、构建身份和读回结果补入证据包。
官方资料
- DevEco Studio 26.0 新特性
- 独立 merged HAR 构建
- 多 target 与产品构建
- ohpm 常用命令
最终结论
从模块图、归档内容、消费工程和运行入口四层验收独立 HAR,避免只看到构建成功就交付。 适配不是让截图“看起来差不多”,而是让关键任务在形态变化后依然可见、可操作、可恢复。](https://i-blog.csdnimg.cn/direct/487968a55f24435e85c0d55b136f7f9a.jpeg#pic_center)