专栏：HarmonyOS 三方库适配实战（17/30）
核心问题：源码工程能编译，为什么交付给别人的是 HAR 时仍可能缺入口、漏文件或被旧依赖掩盖？
摘要
构建出library_adapter.har只是开始。真正的交付验收要回答三件事：候选 HAR 里是否包含应交付的入口和实现；消费者是否确实依赖这一个 HAR；构建结论究竟覆盖到编译、模拟器还是设备运行。本文用一个文本工具库演示完整的 HAR 审计闭环：先定义验收对象，再读归档、校验入口、让消费者仅引用 HAR，最后把失败信号映射到可重验的步骤。
本文仅确认当前工作区的 HAR 与消费者构建层证据。未进行签名、混淆、API 22 模拟器或真机运行，因此不会把“可构建”写成“已上架”或“已在设备通过”。
先把“验收对象”说清楚
许多排查从源码目录开始：看到Index.ets、README 和实现文件都在，就认为包没有问题。这个结论并不成立。消费者拿到的是最终归档，而不是你的源码目录；最终判断必须以候选 HAR 为中心。
| 要回答的问题 | 审计对象 | 通过意味着 | 不意味着 |
|---|---|---|---|
| 文件是否被交付 | 最终library_adapter.har的清单 | 当前候选具备进一步消费条件 | 已在设备运行 |
| 入口是否可定位 | HAR 中的oh-package.json5与Index.ets | 包声明与入口能被检查 | API 行为已经正确 |
| 消费方是否使用 HAR | entry/oh-package.json5的file:依赖 | 当前工程没有直接回退源码模块 | 新电脑已完成独立复现 |
| 构建结果可否追溯 | HAR、release HAR、消费者 HAP 哈希 | 本次候选可被识别 | 未来构建必然字节一致 |
图 1：交付判断从最终 HAR 出发，而不是从 IDE 中的源码树出发。
一个最小但可审计的入口
本例库把公共 API 放在根目录Index.ets，并由oh-package.json5中的main指向该入口。入口的价值不在“导出越多越好”，而在于消费者只有一个稳定的访问面。
exportfunctionnormalizeSpaces(input:string
