arkui 不提供 parentcomponent 引用，状态同步依赖 @prop/@link/@param 等装饰器构建的隐式双向链路；底层通过代理对象与变更通知实现精准刷新，手动引用会引发内存泄漏、刷新失效和跨层级失效。

“parentComponent 引用”并不是 ArkUI 渲染器中一个公开暴露的 API 或内置变量，而是一种对父子组件间状态绑定关系的通俗描述——它指代的是子组件在初始化时，从父组件接收状态数据所依赖的**逻辑上下文来源**。ArkUI 并不直接提供名为 parentComponent 的引用对象，但通过装饰器（如 @Prop、@Link、@Param）在编译和运行时构建出隐式的、强类型的父子同步链路，这才是跨组件状态同步的底层机制核心。

状态同步靠装饰器，不是靠手动取 parent 引用

ArkUI 的设计哲学是声明式、类型安全、编译期可分析。开发者无需也不应尝试通过 this.parent 或类似 DOM 风格方式去获取父组件实例。所有通信都通过装饰器显式声明数据流向：

• @Prop：建立单向同步（父 → 子），子组件可本地改，但不回传；父组件状态更新时，子组件对应 @Prop 值被强制覆盖
• @Link（V1）或 @Param（V2）：建立双向同步，父子任一方修改，另一方立即响应；底层由框架自动维护引用代理，确保对象变更能触发 UI 刷新
• @Provide/@Consume：跨多层组件的状态注入，不依赖直接父子链，而是基于组件树的上下文查找，类似 React Context

底层机制：状态代理与变更通知系统

当使用 @Link 或 @Param 时，ArkUI 实际为变量创建了一个轻量级代理对象（Proxy-based wrapper），该代理持有一个指向父组件原始状态变量的弱引用（或内部句柄），并注册了变更监听器：

• 子组件调用 this.linkedVar = newValue → 触发代理的 set 拦截 → 同步更新父组件源状态 → 父组件标记自身需刷新 → 子组件也收到通知刷新
• 父组件修改源状态 → 通知所有关联的 @Link 代理 → 各子组件同步更新并触发 UI 重绘
• 这种联动不依赖“查找 parent 组件实例”，而是由框架在组件挂载时完成绑定注册，属于编译+运行时协同管理

V1 和 V2 的关键差异影响同步行为

不同版本对状态同步的实现抽象层级不同，直接影响开发习惯：

• V1 使用 @Link，同步逻辑紧耦合在装饰器上；方法调用需配合 Controller 模式才能实现“父调子”
• V2 引入 @Param（替代 @Link）、@Event（用于父向子发事件）、@Local（本地存储）等，职责更清晰：数据输入用 @Param，事件输出用 @Event，避免混合语义
• V2 还支持属性级精准刷新（减少 70% 冗余渲染）和 freezeWhenInactive，说明底层已将状态绑定与组件生命周期深度整合，而非简单引用传递

为什么不该手动维护 parentComponent？

手动保存或查找父组件引用会破坏 ArkUI 的声明式约束，带来三类风险：

• 内存泄漏：强引用父组件可能导致其无法被垃圾回收
• 刷新失效：绕过装饰器机制的赋值不会触发框架的状态追踪，UI 不更新
• 跨层级失效：在嵌套较深或使用 @Provide 场景下，“父组件”概念本身已模糊，硬编码引用失去意义