HarmonyOS 基础入门考点精炼

针对官网免费入门教程与高频考点定向整理，覆盖基础入门全模块易错点，助力提升答题正确率！

一、应用程序包核心考点

1. HAP / HAR / HSP 核心区别

这是考试最高频考点，务必精准区分三者特性，避免概念混淆。

关键概念记忆

1. EntryHAP
   一个应用有且仅有一个；桌面图标启动入口；
2. FeatureHAP
   多个功能分包，不能单独在桌面显示，依靠EntryHAP拉起。

资源覆盖优先级（必考，极易记反）

当前HAP资源 ＞ AppScope资源 ＞ HAR资源
⚠️ 易错点：
HSP属于运行时动态加载机制，不参与编译期资源覆盖规则，不要放进这条优先级链。

经典错题

• ❌ HSP能够独立安装 → 错
• ❌ HAR支持运行时动态共享资源 → 错（编译期拷贝）
• ❌ 多个模块引用HAR只会存在一份代码 → 错（多副本）

2. 资源覆盖优先级

考试中极易搞反顺序，核心规则：就近原则，优先级从高到低为：

1. 当前HAP模块内的资源
2. AppScope全局共享资源
3. 依赖的HAR包内资源

易错提醒：HSP的资源优先级低于当前HAP，高于普通HAR，不要把HSP放在优先级最底层。

3. 应用包结构补充考点

• 一个鸿蒙应用可以包含多个HAP、HAR、HSP，但必须且至少有一个EntryHAP作为应用入口。
• FeatureHAP不能独立出现在设备桌面，必须依托EntryHAP启动。
• HAR不支持在模块中声明UIAbility，仅能提供组件、工具类和静态资源。

二、ArkTS 语言强制规范考点

1. 类型约束

1. 禁止隐式any，变量、函数返回值必须显式标注类型；
2. 类中非空成员变量必须初始化；
3. 禁止eval、with等动态JS特性，代码支持静态类型检查；
4. 空安全：访问可选属性使用 ?.。

2. build() 函数红线（高频判断选择题）

build() 仅允许描述UI组件，禁止：

• 网络请求、文件IO、数据库操作
• 大量循环、复杂同步计算
• 创建定时器、事件订阅
  原因：build会被框架反复调用，会造成重复请求、内存泄漏、卡顿。
  ✅ 正确位置：aboutToAppear、点击回调、异步函数内执行耗时逻辑。

3. 列表渲染 ForEach vs LazyForEach

1. ForEach
   适合少量数据；必须提供稳定唯一key；禁止直接使用数组下标作为key；一次性创建所有组件，长列表性能差。
2. LazyForEach
   大数据长列表专用；组件按需创建，滑出可视区域回收；
   约束：数据源必须实现IDataSource，包含
   totalCount、getData()、数据变更监听回调。

考题套路：上千条列表使用ForEach → 错误实现。
这部分是笔试和实操题的重灾区，大量考生因忽略细节丢分，核心易错点整理如下：

1. 类型系统强制规则

1. 完全禁止隐式any类型，所有变量必须显式声明类型，未标注类型的变量编译器会直接抛出错误。
2. 类的所有属性必须在声明时或构造函数中显式初始化，禁止出现未赋值的非空属性，避免运行时undefined崩溃。
3. 空安全强制校验：访问可能为undefined的属性时，必须使用可选链?.，禁止直接访问属性。
4. 禁止使用eval()、with()、动态生成函数等JS动态特性，所有代码必须支持静态分析。

2. 生命周期函数行为约束

build()函数是UI渲染的核心方法，绝对禁止在其中执行以下操作：

• 发起网络请求、读写本地文件等耗时I/O操作
• 执行复杂循环、大量数据计算等阻塞操作
• 创建定时器、订阅事件等会产生副作用的逻辑

易错提醒：build()函数会被框架多次调用，上述操作会导致重复执行、UI卡顿甚至应用崩溃，正确的做法是在aboutToAppear()等生命周期中执行。

3. 列表渲染核心规则

1. ForEach循环渲染：必须为每个子组件提供唯一且稳定的key值，禁止使用数组索引作为key，否则会出现列表更新错乱。
2. 大数据列表：数据量超过100条时，必须使用LazyForEach懒加载渲染，避免一次性创建大量组件导致内存溢出、页面滑动卡顿。
3. LazyForEach必须实现完整的IDataSource接口，包含totalCount、getData、onDataChangeListener三个核心方法。

三、模块配置文件区分考点

考试中经常混淆不同配置文件的作用范围，核心区分要点如下：

易错提醒：不要在module.json5中修改应用全局版本号，该配置在app.json5中定义；模块独有的页面路由必须在对应模块的module.json5中注册，否则无法跳转。

⚠️ 易错区分

• module.json5：业务配置（组件、页面、权限）
• build-profile.json5：编译打包构建配置

四、高频错题避坑指南

1. 判断题：HSP可以独立安装到设备 → 错误，HSP必须依托主HAP安装，不能独立存在。
2. 选择题：以下哪个操作可以在build()中执行 → 正确选项：仅执行UI组件的声明与布局，排除网络请求、定时器等操作。
3. 选择题：资源覆盖优先级最高的是 → 正确选项：当前HAP模块内资源，不要误选AppScope。
4. 实操题：实现1000条数据的列表展示 → 必须使用LazyForEach，使用普通ForEach会被判定为错误实现。
5. 实操题：类属性定义 → 必须显式初始化，未赋值的非空属性会直接编译报错。

五、备考建议

1. 优先记忆HAP/HAR/HSP的特性对比表，这是第一轮考试正确率最低的考点，必须做到零混淆。

2. 动手实操一遍ForEach和LazyForEach的完整实现，重点掌握唯一key的生成规则。

3. 梳理三个核心配置文件的作用边界，不要混淆各自的配置项。

4. 结合前文的ArkTS文件操作实战代码，巩固类型规范和异步操作的正确写法，应对实操类考题。

5. 包规则：
   只有HAP能安装；HAR静态复制、HSP动态共享；
   资源就近覆盖：当前HAP > AppScope > HAR。

6. ArkTS：
   无隐式any；build只写UI，耗时逻辑移出；
   短列表ForEach，大数据列表LazyForEach，key必须唯一。

7. 配置文件：
   module.json5管页面与Ability；
   build-profile.json5管编译签名；
   app.json5管应用全局包名版本。

判断题高频坑清单

1. HAR可以声明UIAbility → ❌
2. HSP可以独立安装 → ❌
3. build()中发起网络请求合法 → ❌
4. 资源优先级 AppScope > 当前HAP → ❌
5. 长列表直接使用ForEach渲染推荐 → ❌
6. 一个应用可以存在多个EntryHAP → ❌（只能1个）