刚开始学习HarmonyOS开发时，ArkUI有个地方特别容易让人困惑：明明数据已经改了，页面却没有按照预期更新。

尤其是在使用@State管理数组的时候，这类问题更值得注意。

今天就拿一个简单的待办清单来举例，看看ArkUI的状态管理应该怎么处理。

先看一个常见场景。假设我们开发了一个任务列表，每个任务包含三个字段：

interface TaskItem {
  id: number;
  title: string;
  completed: boolean;
}

用户点击任务后，需要把completed从false改成true，并更新页面显示。一个很自然的写法是直接修改数组中的对象：

this.tasks[0].completed = true;

这段代码从JavaScript角度看完全合理。但在ArkUI实际开发中，能不能触发页面刷新，还取决于使用的状态管理机制，以及框架对嵌套数据变化的观察方式。

对于使用传统@State管理的对象数组，直接修改对象内部属性，可能无法得到我们预期的刷新效果。

换一种写法试试

为了让状态变化更明确，可以通过map()生成新数组。

private finishTask(id: number): void {
  this.tasks = this.tasks.map((item: TaskItem) => {
    if (item.id === id) {
      return {
        ...item,
        completed: true
      };
    }

    return item;
  });
}

这里有两个关键点。

第一，没有直接修改原来的任务对象，而是创建了一个新对象。

第二，更新完成后，重新给this.tasks赋值。

对于传统@State数组，这种做法能够更明确地触发状态更新，也便于后续检查数据变化。

列表渲染还有个细节

开发任务列表时，我们通常会用ForEach遍历数据。

ForEach(
  this.tasks,
  (item: TaskItem) => {
    ListItem() {
      Text(item.title)
        .fontColor(
          item.completed ? Color.Gray : Color.Black
        )
    }
  },
  (item: TaskItem) => item.id.toString()
)

这里最值得注意的是最后一行。

ForEach需要稳定的唯一标识来识别列表项，因此最好使用任务ID，而不是数组下标。因为任务删除、排序之后，下标可能变化。如果把下标当成唯一标识，就可能造成组件复用和界面表现方面的问题。

我的建议：不要只盯着@State

另外要注意，HarmonyOS还提供了其他状态管理机制，不同机制对于对象属性变化的追踪方式并不完全相同。因此，如果遇到页面不刷新的情况，我一般建议按下面的顺序排查：

1. 先确认数据是否真的发生变化。
2. 再检查状态变量是否由正确的机制管理。
3. 检查修改的是对象属性，还是整个数组。
4. 查看ForEach的唯一标识是否稳定。
5. 最后确认UI绑定的字段是否正确。

不要一看到页面没变化，就怀疑ArkUI出了问题。很多时候，问题只是出在数据更新方式上。

最后，我想再重点提一下，状态管理是HarmonyOS应用开发的基础知识，看起来简单，但实际项目中非常重要。一个页面可能有几十个状态字段，如果管理方式混乱，后面就会出现各种难以定位的问题。

我更推荐在简单场景下优先使用清晰、可预测的数据更新方式，等真正理解状态管理机制之后，再根据项目需求选择更合适的方案。把每一次状态变化写清楚，比盲目追求代码简短更重要。

这也是从写Demo到开发正式应用过程中，很值得掌握的一项基本功。