2-6.【ArkTS】@State、@Prop、@Link、@Provide、@Consume 的底层机制是什么？为什么 @State 只能定义在组件内部？

@State、@Prop、@Link、@Provide、@Consume 的底层机制是什么？为什么 @State 只能定义在组件内部？@Link 与 @Prop 的核心差异？

在 ArkUI 的声明式框架中，这些装饰器并非简单的“语法糖”，它们共同构成了 数据驱动 UI（Data-Driven UI） 的核心引擎。其底层逻辑是一套基于 观察者模式（Observer Pattern） 的状态订阅机制。

ArkTS 装饰器的核心由 两个关键组件 驱动：

数据代理 (Proxy/Setter Interception)： 当你给变量加上 @State 等装饰器时，ArkCompiler 会在编译阶段修改属性的访问器（Getter/Setter）。
订阅器 (Subscriber)： 每个状态变量内部都维护了一个监听列表。
- 读 (Getter)： 当组件的 build() 函数读取该变量时，框架记录下“这个组件依赖这个变量”。
- 写 (Setter)： 当变量值改变，Setter 被触发，它会立刻通知所有“依赖它的组件”进行局部重新渲染。

@State 的设计初衷是 “组件的私有状态管理” ，其限制主要源于以下考量：

生命周期绑定： @State 变量的生命周期与所在的 @Component 完全同步。当组件销毁时，该状态所占用的内存和订阅关系会被自动回收。如果允许定义在外部，会引发内存泄漏和不可预测的引用问题。
渲染上下文约束： @State 需要知道它归属于哪个渲染节点，以便在数据变化时触发该节点的 build() 方法。外部定义的普通变量没有这种“渲染上下文”。
单向依赖源： 在 ArkUI 的架构中，@State 被定义为 “数据的源头（Source of Truth）” 。所有的复杂交互（通过 @Prop 或 @Link）都应该追溯到一个明确的 @State 节点。

这是开发者最容易混淆的地方，本质区别在于 “数据的所有权” 和 “同步方向” 。

特性	@Prop	@Link
同步方向	单向同步 (父 $\rightarrow$ 子)	双向同步 (父 $\leftrightarrow$ 子)
底层实现	深拷贝 (Deep Copy) 。子组件维护一份独立的数据副本。	引用传递 (Reference) 。子组件操作的是父组件状态的指针。
性能开销	较高（涉及数据复制，特别是大对象）。	极低（仅传递引用）。
修改限制	子组件可以修改，但不会影响父组件。	子组件修改后，父组件及所有链接的组件同步刷新。
典型场景	纯展示组件、表单的临时编辑（取消则不保存）。	输入框、复选框等需要反馈给父层逻辑的交互。

如果你有 React 开发经验，这类似于 Context API。

底层机制： 框架通过 层级搜索（Component Tree Search） 实现。当一个组件声明了 @Consume，它会沿着 UI 树向上寻找最近的、匹配相同 Key 的 @Provide。
解耦优势： 它避免了“属性钻取（Prop Drilling）”，即不需要通过中间组件一层层手动传递 @Link。
代价： 这种查找机制比直接引用略重，且如果 Key 重名可能会导致意外的状态覆盖。

在实际工程中，选择装饰器的逻辑应当如下：