鸿蒙开发中最容易被误解的三兄弟：@State、@Prop、@Link 到底怎么用？

大家好，我是你们熟悉的鸿蒙自媒体博主 Echo_Wish。
今天咱们来聊一个很多鸿蒙（ArkUI）开发者刚入门时都会踩的坑：状态管理。

你是不是也曾经历过下面这几个瞬间：

• 页面变量明明改了，UI就是不刷新？
• 我传了个值给子组件，结果它却改不了？
• 明明要共享状态，但怎么传都不优雅？

没错，这些问题的本质都是 @State、@Prop、@Link 的使用场景没分清。

它们就像三兄弟，看着相似，但性格完全不一样。
用对了，代码丝滑；用错了，心态崩掉。

今天，我们就把它们彻底说透。

一、引子：UI不是“画出来的”，是“算出来的”

ArkUI 的一个核心理念：
UI = f(state)
也就是：UI 是根据状态计算得来的。

当状态变化时，UI才会自动刷新。
所以，状态类型选错，UI 自然不会动。

状态管理不是语法技巧，是组件通信的底层逻辑。

想清楚一个问题，你就不会再乱用：

这个变量是谁拥有的？谁可以改？改完是否要刷新UI？

二、原理讲解：三兄弟的性格图（通俗易懂）

一句话记忆：

@State 自己用的，@Prop 父给你的，@Link 父子一起用的。

三、实战代码示例：用最常见的“计数器”讲清

1) @State：自己玩自己的

@Entry
@Component
struct CounterStateDemo {
  @State count: number = 0;

  build() {
    Column() {
      Text(`当前计数：${this.count}`)
      Button("点我+1")
        .onClick(() => {
          this.count += 1; // 本组件自己改，UI自动刷新
        })
    }
  }
}

@State → 内部自带刷新能力，适合组件自己管理数据。

2) @Prop：父给子用，但你别动

@Component
struct ChildTitle {
  @Prop title: string; // 子组件只读

  build() {
    Text(this.title)
  }
}

@Entry
@Component
struct Parent {
  build() {
    ChildTitle({ title: "我是父组件传来的标题" })
  }
}

子组件只能用 title，不能改它。
想改？那必须父组件自己改，然后重新传递。

3) @Link：父子共用一个变量

@Component
struct ChildCounter {
  @Link count: number;

  build() {
    Button(`子组件加1：${this.count}`)
      .onClick(() => {
        this.count++; // 改的其实是父组件的 count
      })
  }
}

@Entry
@Component
struct ParentCounter {
  @State count: number = 0;

  build() {
    Column() {
      Text(`父组件显示：${this.count}`)
      ChildCounter({ count: $count }) // 注意这里是：$count
    }
  }
}

子组件按钮点一下，父组件数字也变，这就是共享状态。

⚠️ 关键点：@Link 在传的时候必须用 $变量
不然只是传值，而不是传引用。

四、场景应用：到底什么时候用谁？

再用一句人话解释：

• 你自己的小心事 → @State
• 父母给你的零花钱，但不能乱花 → @Prop
• 家庭共同账户 → @Link

是不是一下子就明白了？😁

五、Echo_Wish式思考：状态不是工具，是思想

很多人学框架总想先记语法，但真正决定你写得顺不顺的，是你理解不理解“数据是谁的”。

鸿蒙的状态管理，其实是在推动我们思考：

组件是独立的，数据责任也是独立的。
能自己管就自己管，需要共享就声明共享，该只读就别乱改。

你会发现：

• 项目越大，越要减少混乱的状态流动
• @State 和 @Prop 越分得清晰，代码越稳定
• @Link 用少比用多更高级

最终，你写的不是“页面”，而是关系清晰、自洽的系统。

❤️ 最后一句话（敲黑板）

UI 不会因为你想让它变而变，它只会因为“状态”变而变。

学会管理状态，就是学会掌控 UI。
当你真正用明白了 @State、@Prop、@Link，
你就已经迈入了专业鸿蒙开发者的门槛。