1. ArkTS 与 TypeScript 的核心差异
Q1: ArkTS 为什么限制了 any 和 unknown 类型？
答案核心 ：
为了实现 AOT (Ahead-Of-Time) 编译优化 。
TS 的 any 允许在运行时动态改变类型，这会导致编译器无法确定对象的内存布局，必须在运行时进行大量的类型检查和查找（JIT 编译器的负担）。ArkTS 通过强制静态类型，使得编译器能确定对象布局，直接生成高效的机器码，从而显著提升应用启动速度和运行性能。
Q2: 在 ArkTS 中如何处理来自 JS 库的未知类型对象？
答案核心 ：
使用 ESObject 类型。
由于 ArkTS 禁用了 any，当需要与传统的 JS/TS 库交互时（例如调用第三方库返回的对象），应将其类型声明为 ESObject。这告诉编译器该对象是一个动态类型对象，需要特殊处理，但应尽量减少 ESObject 的在跨语言边界之外的使用，以避免性能损耗。
Q3: ArkTS 对 Interface 和 Class 的使用有什么特殊限制？
答案核心：
- 对象字面量限制 ：ArkTS 不支持直接使用对象字面量赋值给接口类型（除非该接口完全符合结构化类型且无方法）。推荐使用
class来实例化对象。 - 运行时修改限制 ：ArkTS 不支持在运行时动态添加或删除对象的属性（
delete obj.prop是禁止的），这又是为了保证对象内存布局的稳定性，利于性能优化。
2. 语法与特性
Q4: 简述 ArkTS 中的装饰器及其作用。
答案核心 ：
ArkTS 利用装饰器来实现声明式 UI 和状态管理。
- 类装饰器 ：如
@Component（定义组件）、@Entry（定义页面入口）、@CustomDialog（定义弹窗）。 - 属性装饰器 ：如
@State（组件内状态）、@Link（双向同步）、@Prop（单向同步）、@BuilderParam（UI 槽位）。 - 方法装饰器 ：如
@Builder（轻量级 UI 复用）。
原理：装饰器本质上是编译器的一种元数据标记，编译器在处理时会根据装饰器生成相应的胶水代码（如状态监听、UI 更新逻辑）。
Q5: ArkTS 中的闭包（Closure）有什么限制？
答案核心 ：
在 ArkTS 中，闭包捕获的变量必须是明确类型的。
- 只有在
Arrow Function（箭头函数）中才能捕获局部变量。 - 如果闭包被传递到非当前作用域执行（例如异步回调），捕获的变量需要小心内存泄漏。
- 在 UI 描述（
build函数）中，闭包常用于事件回调，此时闭包捕获this上下文是自动处理的，指向当前组件实例。
Q6: Record 类型与 Map 在 ArkTS 中有何区别？
答案核心：
- Record<K, V> ：是 TS 的工具类型，本质上是对象
{}。在 ArkTS 中，它用于定义具有固定键值类型的纯数据对象。 - HashMap / Map ：是 ArkTS 提供的高性能容器类（
@kit.ArkTS）。
选择建议： - 如果只是简单的数据传输对象（DTO），用
Record或Class。 - 如果需要频繁增删改查、获取大小、迭代操作，必须 使用
HashMap或Map，因为 ArkTS 对原生对象的动态操作有限制。
3. 内存与并发基础
Q7: ArkTS 的内存模型与传统 Java/Kotlin 有什么不同？
答案核心 ：
ArkTS 采用 Actor 并发模型 ，线程间内存隔离。
- 无共享内存：不同线程（如 UI 主线程和 Worker 线程）之间不共享对象。
- 通信机制 ：通过 序列化 (Serialization) 或 所有权转移 (Transferable) 进行数据交互。
- 优势：消除了多线程竞争（Race Condition），无需使用锁（Lock），彻底解决了死锁问题。
Q8: 什么是 Sendable 对象？
答案核心 ：
Sendable 是 ArkTS 引入的一种特殊对象类型，用于解决 Actor 模型下跨线程通信效率低的问题。
- 被
@Sendable装饰的类，其实例可以在线程间引用传递（Shared Reference），而不是拷贝。 - 限制 ：
Sendable对象必须是冻结的（属性不可变）或者使用特定的锁机制（如AsyncLock）来保证线程安全。 - 场景：大对象传输、跨线程共享配置。
别再犹豫，海量面试真题库已备好！
👇👇👇👇👇👇