大家好，我是杨利杰 YJlio。

上一节我把数量放在页面的 @State count 中。这一节继续拆分页面：父组件保留“增加”按钮，子组件负责显示数量。我的目标是把状态归属、参数传入和后续同步分别看清楚。

本文属于学习计划第 017 篇，计划日期为 2026 年 10 月 7 日。原稿保留在批次素材目录；下方父子组件代码是围绕本篇主题补充的学习示例，尚未在本机编译或设备运行。配图均为概念示意。

一、拆组件之前，先确定谁管理状态

我先把职责写下来：父组件保存 count 并处理按钮事件，子组件接收 value 并展示文字。这样，点击与数据修改发生在同一个父组件中，子组件的显示内容则沿着参数关系更新。

先确定状态由谁管理，再决定用什么方式传给子组件。

这里的父子关系来自组件调用，不是页面上的上下位置。子组件即使在布局中出现在按钮上方，仍由创建它的父组件传入参数。

二、count 与 value，是两个不同的字段名

本例中，父组件字段叫 count，子组件字段叫 value。创建子组件时使用 CountView({ value: this.count })：左侧 value 对应子组件字段，右侧 this.count 指向父组件当前的状态。

我会先沿着这条关系检查名称。把参数写成 count，却只在子组件声明 value，并不能建立预期的对应关系。组件名 CountView 也必须与定义一致。

三、父组件：保留状态和增加按钮

父组件使用 V1 状态管理写法，初始 count 为 0。按钮事件中只做一件事：给 count 加 1。父组件创建 CountView 时，把自己的状态作为 value 的来源。

本篇采用下面这份完整的最小页面示例：

@Component
struct CountView {
  @Prop value: number = 0;

  build() {
    Text(`子组件数量：${this.value}`)
  }
}

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

  build() {
    Column() {
      CountView({ value: this.count })
      Button('增加').onClick(() => {
        this.count += 1
      })
    }
  }
}

代码使用 @Component、@State、@Prop 这一组 V1 写法。若当前工程使用 V2 模板，应按该模板的状态管理规则另行适配，不能把不同体系的装饰器混进同一个示例。学习系列名称也不代表这段代码已经通过某个 SDK 版本的验证。

四、子组件：用 @Prop 接收并显示 value

CountView 的 value 是 number 类型，声明了本地默认值 0。Text 读取的是 this.value，文案前缀为“子组件数量：”。

在本例中，父组件实际传入了 this.count，因此初始化时使用这个传入值。默认值是字段声明的一部分，不代表有父组件传参时仍固定显示 0。

按照示例的逻辑，初始应显示“子组件数量：0”；点击增加后应跟随父状态变化。这是预期行为，实际显示仍需在练习工程中记录。

五、单向同步：父组件更新，子组件跟随

依据华为 @Prop 文档，本例的观察状态可从父组件同步到子组件。父组件 count 改变后，子组件对应的 value 接收更新，依赖它的显示内容随之变化。

@Prop 并不是禁止子组件修改值。它允许本地修改，但该修改不会沿这条关系回写父组件；父组件以后再次更新来源值时，子组件会接收新的值。本例没有安排子组件修改操作，先只观察父到子的路径。

@Prop 是父到子的单向同步，不能把子组件本地修改理解为父状态已经改变。

六、初始化传参，与后续同步分别检查

我不会只凭“创建时传了参数”，就判断以后一定会同步。声明方式和数据来源共同影响更新规则。

检查位置	本例采用的方式	我需要区分的情况
父组件数据	@State count	普通变量变化未必触发观察更新
子组件字段	@Prop value	普通字段与本地状态字段有各自规则
创建组件	value: this.count	初始化对应正确，还要检查后续观察关系
默认值	value 的本地初值为 0	默认值与父组件实际传入值不是同一件事

如果初始化能显示，点击后却没有变化，我会依次检查按钮有没有执行、是否修改了父组件的观察状态、创建位置是否传入同一个字段，以及子组件 Text 是否读取了 value。

七、number 示例的结论，不直接推广到复杂对象

这次只传一个 number，便于看清方向。对象复制、嵌套属性变化和特殊类型支持是另外的问题，不能从这个数量示例推断所有复杂数据都有相同行为。

我会保留最小示例，之后再单独练习对象传递，并对照工程对应版本的官方文档。出现编译错误时先保存完整诊断，核对组件声明和支持范围，再记录修订过程。

八、把验证记录写成可复现的父子路径

练习时，我按“父 count → 参数 value → 子 Text”的顺序记录。先确认初始值，再逐次点击；每次同时核对事件执行、父数据和子组件显示，避免只看最终画面猜原因。

项目	预期或待记录内容	当前状态
工具与 SDK	实际 DevEco Studio、工程 SDK/API 版本	待填写
运行目标	模拟器或真机型号、系统版本	待填写
初次显示	按示例逻辑预期为子组件数量：0	待实际验证
点击一次	按示例逻辑预期为子组件数量：1	待实际验证
再次点击	检查父状态与子显示是否继续一致	待实际验证
编译或运行异常	完整错误文本、操作步骤、修订差异	待实际记录

预期结果用于指导验证，实际结果必须来自真实工程和设备记录。

写在最后

这节我把一个数量页面拆成两个职责：父组件管理数量，子组件显示传入值。真正需要记住的是字段对应清楚、状态归属明确、同步方向可追踪。

下一篇继续学习自定义组件的拆分与复用，在同一套最小示例上观察结构变化。

参考资料

1. 华为开发者文档：@Prop 装饰器——父子单向同步。本文用其说明 V1 的概念，实际工程请选用对应版本文档。
2. 华为开发者文档：@State 装饰器——组件内状态。
3. 本系列第 017 篇原稿：《父子组件参数与状态传递》，计划日期 2026-10-07。

---

声明：本文为个人学习笔记；示例与配图用于说明思路，尚无本机编译或设备实测记录。实际行为以工程所用 SDK、对应文档及运行结果为准。

返回顶部