HarmonyOS鸿蒙Next中打包后har包在加载项目中时报10311002 ArkTS: ERROR
HarmonyOS鸿蒙Next中打包后har包在加载项目中时报10311002 ArkTS: ERROR har包所在模块中的build-profile.json5中写的配置文件信息:
"buildOptionSet": [
{
"name": "release",
"arkOptions": {
// "byteCodeHar": false,
"obfuscation": {
"ruleOptions": {
"enable": false,
"files": [
"./obfuscation-rules.txt"
]
},
"consumerFiles": [
"./consumer-rules.txt"
]
}
},
},
],
如果将byteCodeHar设置为true,直接把源码打包,这样生成的har包加载到项目中就没有报错,而设置为false时,所生成的har包就无法成功加载进去,报了如下错误:
hvigor ERROR: ArkTS Compiler Error
1 ERROR: 10311002 ArkTS: ERROR
Error Message: Failed to resolve OhmUrl. Failed to get a resolved OhmUrl for “hvigor_ignore_W:BluetoothProject_BluetoothOBU_HarmonyOSBleProject2_oh_modules.ohpm_ccc_jiangsu@girda0nwedqkq63iqg0n50ny10zg9thbucl6gkft+6w=_oh_modules_ccc_jiangsu_Index.d.ets” imported by “W:\BluetoothProject\BluetoothOBU\HarmonyOSBleProject2\entry\src\main\ets\pages\HandlerBleOBUPage.ets”.
- Try the following:
Check whether the “undefined” module which hvigor_ignore_W:BluetoothProject_BluetoothOBU_HarmonyOSBleProject2_oh_modules.ohpm_ccc_jiangsu@girda0nwedqkq63iqg0n50ny10zg9thbucl6gkft+6w=_oh_modules_ccc_jiangsu_Index.d.ets belongs to is correctly configured.
Check if the corresponding file name “hvigor_ignore_W:BluetoothProject_BluetoothOBU_HarmonyOSBleProject2_oh_modules.ohpm_ccc_jiangsu@girda0nwedqkq63iqg0n50ny10zg9thbucl6gkft+6w=_oh_modules_ccc_jiangsu_Index.d.ets” is correct(including case-sensitivity).
COMPILE RESULT:FAIL {ERROR:2 WARN:31}
更多关于HarmonyOS鸿蒙Next中打包后har包在加载项目中时报10311002 ArkTS: ERROR的实战教程也可以访问 https://www.itying.com/category-93-b0.html
问题分析
byteCodeHar配置被注释:您配置中byteCodeHar被注释掉了,这个配置对HAR包的构建类型至关重要- 混淆配置可能冲突:虽然混淆被禁用了(
enable: false),但配置文件的存在可能导致构建工具处理逻辑异常 - HAR包类型不匹配:加载项目期望的HAR包类型与实际构建的类型不一致
解决方案
方案1:启用字节码HAR(推荐)
修改您的 build-profile.json5 配置,取消注释并明确设置 byteCodeHar:
"buildOptionSet": [
{
"name": "release",
"arkOptions": {
"byteCodeHar": true, // 关键配置:启用字节码HAR
"obfuscation": {
"ruleOptions": {
"enable": false,
"files": [
"./obfuscation-rules.txt"
]
},
"consumerFiles": [
"./consumer-rules.txt"
]
}
}
}
]
方案2:如果必须使用源码HAR
如果确实需要源码HAR,需要完整配置并确保路径正确:
"buildOptionSet": [
{
"name": "release",
"arkOptions": {
"byteCodeHar": false, // 明确设置为false
"obfuscation": {
"ruleOptions": {
"enable": false
}
}
}
}
]
方案3:工程级配置同步
检查项目根目录下的 build-profile.json5,确保有正确的全局配置:
{
"app": {
"signingConfigs": [...],
"useNormalizedOHMUrl": true // 确保这个配置存在
},
"modules": [
{
"name": "您的har模块名称",
"buildOption": {
"arkOptions": {
"byteCodeHar": true
}
}
}
]
}
完整排查步骤
-
清理构建缓存:
- 在DevEco Studio中:
File→Invalidate Caches→Invalidate and Restart - 手动删除项目下的
build和hvigor缓存目录
- 在DevEco Studio中:
-
重新构建HAR包:
hvigorw --clean # 清理 hvigorw assembleHap # 重新构建 -
验证HAR包内容:
- 检查生成的HAR包是否包含正确的文件结构
- 字节码HAR应包含
*.abc文件,而不是*.ets源文件
-
检查依赖版本:
- 确保主项目和HAR包使用相同的API版本和SDK版本
- 在
oh-package.json5中检查依赖版本兼容性
预防措施
- 统一配置管理:确保所有模块的
build-profile.json5配置一致 - 版本控制:HAR包发布到ohpm时,明确标注是字节码版本还是源码版本
- 测试验证:在发布前,先在测试项目中验证HAR包的引用是否正常
更多关于HarmonyOS鸿蒙Next中打包后har包在加载项目中时报10311002 ArkTS: ERROR的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
这个问题本质上是:
以后,HAR 里带的是 ArkTS 源码。
主工程引用时:
会重新参与编译。
然后 ArkTS 编译器解析源码路径失败了,所以报:
10311002 ArkTS: ERROR
Failed to resolve OhmUrl
而:
"byteCodeHar": true
打进去的是字节码,不需要主工程再编译源码。
所以就正常。
⸻
你这个不是业务代码问题。
是 HarmonyOS 当前:
- 源码 HAR
- Windows
- ohpm依赖
- 多模块
这几个组合下,很容易触发的兼容问题。
⸻
尤其你日志里:
hvigor_ignore_W:
已经说明:
是 Windows 路径解析炸了。
⸻
目前最简单稳定的方案:
直接:
"byteCodeHar": true
很多正式项目现在都是这么做。
⸻
如果一定要源码 HAR,可以尝试:
- 升级 DevEco
- 升级 SDK
- 用 Mac/Linux 编译
- 减少 HAR 内部 ohpm 依赖
但本质还是 ArkTS 编译器兼容问题。
参考《编译报错“Failed to get a resolved OhmUrl by filepath xx”》这个排查下。
有你这个情况。
HAR 包的模块解析失败,核心问题:
- byteCodeHar: false 时,HAR 包以源码形式分发,依赖的 .d.ts 声明文件路径解析失败
- OhmUrl 解析失败:编译器无法找到 ccc_jiangsu 模块的类型定义文件
- 依赖传递问题:HAR 包内部引用的第三方库在宿主项目中找不到对应路径
解决方案:
方案一:修改 HAR 包的构建配置,"byteCodeHar"配置为true,启用字节码模式,避免源码路径问题。这是官方推荐的方式,字节码模式不暴露源码,安全性更好,编译速度更快。
方案二:byteCodeHar还是设置为false,检查Har包的index.ets文件,不要导出内部依赖的第三方库,比如“ccc_jiangsu”;在宿主项目根目录安装缺失依赖(ohpm install ccc_jiangsu);修改宿主项目的 oh-package.json5。重新编译构建
错误码10311002表明ArkTS编译异常。常见原因:har包编译时依赖的SDK版本与加载项目不兼容;har包内部存在循环依赖或重复导出;或使用了加载项目不支持的API。请检查har包build-profile.json5中的compileSdkVersion与项目一致,并确保har包未引用项目外资源。
当 byteCodeHar 设置为 false 时,HAR 包以源码形式发布,消费者工程会将其源码作为自身代码编译。报错 10311002 提示 OhmUrl 解析失败,通常是因 HAR 的模块声明文件(如 Index.d.ets)路径过深或包含特殊字符,导致 Hvigor 生成内部忽略路径时解析异常。根本原因是 HAR 工程依赖层级、oh_modules 嵌套过深,或 oh-package.json5 导出配置与文件路径不匹配。
解决方案:
- 优先保持
byteCodeHar为true(Release 推荐),直接打包字节码可规避此类路径解析问题。 - 若必须使用源码 HAR,请检查 HAR 模块的
oh-package.json5,确保main字段正确指向Index.ets;清理并扁平化依赖树,避免过深的oh_modules嵌套。 - 删除消费者项目的
oh_modules、build目录后重新同步并编译;同时确认混淆配置consumerFiles中的文件存在且内容正确。
通常推荐 byteCodeHar 设为 true,既能保护源码,又能提升编译兼容性。,

