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场景下，“父组件”概念本身已模糊，硬编码引用失去意义
