【鸿蒙心迹】ohpm 与包管理实录：HAR、HSP 怎么选，三方库怎么接

前言

上一篇给应用装上了桌面卡片，功能面铺开之后工程侧的问题跟着来了：网络请求不想手写、日志想统一格式，模块一拆多，"代码放哪个包、包之间怎么依赖"就成了每天都要回答的问题。这篇把码上清单的包管理实践记录下来：ohpm 怎么用、HAR 和 HSP 怎么选、三方库找不到鸿蒙版怎么办。

一、ohpm：先会用再说

ohpm 是鸿蒙的包管理器，心智上接近 npm：依赖声明在模块的 oh-package.json5 里，装包、查版本、锁版本一套流程。几个日常命令：

ohpm install                 # 按 oh-package.json5 装依赖
ohpm install @ohos/xxx       # 直接装某个包
ohpm list                    # 看当前依赖树

实操建议两条：版本号写明确范围，别无脑用最新——三方库改版对编译期的打击是直接的；lock 文件进版本库，团队里装出两棵不同的依赖树这种事，一把锁就能杜绝。

二、HAR 与 HSP：静态复制和动态共享

自己的代码拆包，只有两种容器，选错会在包体积和启动速度上还债：

• HAR（静态共享包）：编译期把代码复制进每一个用到它的 HAP。简单、稳、没有运行时依赖问题，代价是多个入口都用它时，包体积按份数涨。
• HSP（动态共享包）：运行时共享同一个实例。体积省了、跨模块单例能成立了，但约束也多：版本必须严格一致，所有引用方同步升级。

我的选型经验：工具层（网络封装、日志、工具函数）用 HAR，求稳；大体量的公共业务组件或资源用 HSP，求体积；拿不准就 HAR，它几乎不会让你返工。有一个点值得单独记：HSP 的"单实例"是它最大的价值，也最容易踩——HSP 里的全局状态是全应用共享的，别在 HAR 心智下假设"每个入口各有一份"。

三、三方库集成实录

接三方库的路径：先在 ohpm 仓库搜 @ohos/ 前缀的包（社区移植版大多按这个约定命名），看维护活跃度和最近提交；再在自己的工程里装、编译、跑一个最小用例。

码上清单接的是网络和日志两类。集成顺利与否基本取决于一件事：这个库是不是"纯 TypeScript 逻辑"。纯逻辑的 npm 包（不碰 DOM、不碰原生）移植成本低，多数能直接用或小改；一旦涉及原生能力，就得走下面第二条路。

找不到现成鸿蒙版时，三条路按成本排：

1. 源码直移：纯 TS 的包，clone 下来改掉不兼容 API，打成 HAR 私用；
2. 重新实现：库的功能面不大时，自己写比移植维护别人的旧代码便宜；
3. NAPI 桥接：功能重且依赖 C/C++ 实现的，用 NAPI 包原生库——成本最高，除非核心价值就在那份原生实现里，否则不碰。

四、踩坑三条

1. 依赖冲突在 ohpm 这里更"刚"：版本对不上直接报错终止，不像有的生态先装上再说。冲突时以 lock 文件和依赖方声明的范围为准，把版本收窄到公共交集，别用通配符和稀泥。
2. install 卡住先查网络：公司内网、代理环境下 ohpm 拉包超时的表现是长时间无输出，配好仓库镜像或代理再装，别反复重试浪费时间。
3. 含 native so 的库看 abi：真机和模拟器的架构不同，装完在模拟器跑崩，先确认 so 是否覆盖了对应架构，别急着怀疑自己的代码。

小结

包管理理顺，工程就可以放心长大。下一篇回到 UI 主线：一多适配——把码上清单从手机搬到折叠屏，断点与栅格的正确打开方式。

*本文环境：DevEco Studio 5.x / HarmonyOS NEXT（API 14+）/ ohpm。包管理细节以官方《ohpm 使用指南》《HAR/HSP 开发指南》为准。系列上一篇：《【鸿蒙心迹】桌面卡片实战》。*