作为一名大学生，我每天最常做的事情之一就是找自习室。期末周尤其明显：图书馆热门区域很快坐满，教学楼有些教室明明没人，却不一定知道能不能进去自习。

所以在学习 HarmonyOS 开发时，我给自己定了一个小目标：做一个校园自习室助手，至少能够展示不同自习区域的空位情况，并允许用户收藏常去的地方。

第一次写页面，我就遇到了一个问题

刚开始学习 ArkUI 时，我以为只要把数据写进变量，再把变量显示到页面上就可以了。后来才发现，界面展示和状态管理之间有一套需要理解的规则。

例如，我想让用户点击按钮后收藏一个自习区域。如果只修改普通变量，页面不一定会按照预期更新。对于需要驱动界面的状态，我开始尝试使用 @State。
@Entry
@Component
struct StudyRoomPage {
  @State roomName: string = '图书馆三楼';
  @State availableSeats: number = 12;
  @State favorite: boolean = false;
 
  build() {
    Column({ space: 16 }) {
      Text(this.roomName)
        .fontSize(24)
        .fontWeight(FontWeight.Bold)
 
      Text(`当前空位：${this.availableSeats}`)
 
      Button(
        this.favorite ? '取消收藏' : '收藏自习室'
      )
        .onClick(() => {
          this.favorite = !this.favorite;
        })
 
      Button('模拟有人入座')
        .onClick(() => {
          if (this.availableSeats > 0) {
            this.availableSeats--;
          }
        })
    }
    .padding(20)
  }
}

这只是一个用于学习状态管理的模拟页面，空位数据并不是从真实教室获取的。但通过这个小例子，我终于直观地理解了：界面不只是把数据摆出来，状态变化也会影响用户看到的内容。

真正的校园应用，数据从哪里来？

完成页面后，我又想到一个问题：如果空位数字是我手动写的，那这个应用其实没有太大价值。

目前，我更愿意把它设计成一个逐步完善的课程项目。第一阶段允许管理员手动更新自习室状态；第二阶段再考虑接入学校开放的数据接口，或者通过学生自主上报来补充信息。

这里必须注意，学生上报的“空位”不等于真实座位状态。页面应该标注数据更新时间，避免同学跑到现场才发现位置已经被占用。

学习 HarmonyOS，最好从自己真正需要的功能开始

以前看技术教程时，我经常记住了语法，却不知道什么时候应该使用它。做了这个小项目后，我发现状态管理、组件布局和事件处理突然都有了实际意义。

接下来，我还想加入区域筛选、收藏列表和最近使用记录。如果项目继续扩展，我也会把数据读取、页面展示和收藏逻辑拆开，避免所有代码都堆在一个组件里。

这个项目还很简单，但它让我明白了一个道理：学生学习开发，不一定要一开始就做一个功能复杂的大应用。先解决身边一个具体的小问题，再逐步完善功能，反而更容易坚持下去。