前言

点赞按钮很小，但它最能暴露交互代码写得稳不稳。很多页面点完之后只改一个数字，用户会怀疑自己到底有没有点中；也有人把动画和点赞结果绑得太死，接口失败时回滚就乱了。

在 HarmonyOS7 里，animateTo 很适合处理这种短促反馈。我的习惯是把业务状态和动画状态拆开：liked 管结果，iconScale 管视觉反馈。动画负责让用户看见操作，业务状态负责表达真实结果。

为什么这个问题经常被写乱

animateTo 写点赞动画很顺手 这类内容很容易被写成“代码能跑就算讲完了”，但对初学者来说，这恰恰是最不够的地方。真正让人卡住的，往往不是某个组件名记不住，而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。

所以这篇文章不只想给你一个能跑的例子，更想把背后的判断过程讲清楚。你只要把这个判断过程吃透，后面自己改页面、补需求、查问题时，心里会稳很多。

点赞动画要解决什么

点赞交互通常有三个动作：图标变色、数字变化、图标轻微放大再回落。它们看起来像一件事，代码里最好分清楚。

状态	作用	建议
liked	是否已点赞	业务状态，后续可接接口回滚
likeCount	点赞数量	跟随 liked 变化
iconScale	图标缩放	只服务动画，结束后回到 1

动画时间不要太长。点赞属于高频轻操作，120ms 到 200ms 通常就够了；再长会显得按钮反应慢。

先把页面目标想清楚

在真正写代码之前，先别急着盯着 API。更有用的做法是先想清楚：这个页面到底想解决什么问题，用户最在意的反馈是什么，哪些状态必须一直保持一致。

当你先把这条主线想明白，再回头看组件和状态设计，很多选择都会顺理成章。对小白来说，这一步尤其重要，因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。

完整 ArkTS 示例

下面这个页面模拟一张文章反馈卡片。点击整行都能触发点赞，图标会有一个放大反馈，数量也会同步变化。

@Entry
@Component
struct LikeFeedbackPage {
  @State liked: boolean = false
  @State likeCount: number = 126
  @State iconScale: number = 1

  private toggleLike(): void {
    const nextLiked: boolean = !this.liked

    animateTo({ duration: 120, curve: Curve.EaseOut }, () => {
      this.iconScale = 1.22
    })

    animateTo({ duration: 160, curve: Curve.EaseInOut }, () => {
      this.liked = nextLiked
      this.likeCount += nextLiked ? 1 : -1
      this.iconScale = 1
    })
  }

  build() {
    Column({ space: 18 }) {
      Text('这篇 HarmonyOS7 笔记有帮助吗？')
        .fontSize(20)
        .fontWeight(FontWeight.Bold)
        .width('100%')

      Row({ space: 12 }) {
        Text(this.liked ? '♥' : '♡')
          .fontSize(36)
          .fontColor(this.liked ? '#E53935' : '#555555')
          .scale({ x: this.iconScale, y: this.iconScale })

        Column({ space: 4 }) {
          Text(this.liked ? '已点赞' : '点个赞')
            .fontSize(16)
            .fontWeight(FontWeight.Medium)
          Text(`${this.likeCount} 人觉得有用`)
            .fontSize(12)
            .fontColor('#777777')
        }
        .alignItems(HorizontalAlign.Start)
        .layoutWeight(1)
      }
      .padding(16)
      .backgroundColor(Color.White)
      .borderRadius(12)
      .onClick(() => this.toggleLike())
    }
    .justifyContent(FlexAlign.Center)
    .padding(16)
    .backgroundColor('#F5F7FA')
    .width('100%')
    .height('100%')
  }
}

把关键代码一段段拆开

toggleLike() 先算出 nextLiked，再在动画闭包里更新状态。这样数量变化是围绕下一次点赞结果来的，不会因为读旧值而写反。

iconScale 没有参与业务判断。它只在点击时变成 1.22，随后回到 1。以后接入真实接口时，即使点赞失败要回滚 liked 和 likeCount，也不会牵扯动画状态。

点击事件放在整行 Row 上，而不是只放在心形字符上。移动端按钮热区太小会很难点，尤其是用户单手操作时。

接真实接口时怎么改

如果点赞结果来自服务端，可以先做乐观更新，再在接口失败时回滚。这里要注意，回滚的是业务状态，不是动画状态。

private rollbackLike(previousLiked: boolean, previousCount: number): void {
  this.liked = previousLiked
  this.likeCount = previousCount
  this.iconScale = 1
}

这个方法看起来简单，但边界很清楚：失败时把页面恢复到点击前，用户不会看到“图标红了但数量没变”这种拧巴状态。

新手最容易踩的坑

这一类示例最容易让人产生错觉：界面出来了，就以为已经掌握了。其实真正容易出问题的地方，通常都在效果之外，比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。

所以你练这篇内容时，别只看“现在能不能跑”，还要继续看“以后好不好改”。能把这个习惯养起来，你写出来的页面会比单纯照着示例拼出来的页面稳很多。

放进真实项目还要补什么

示例代码的重点是把核心思路讲明白，所以很多工程化细节会故意省掉。真正落到项目里时，你通常还要继续补接口联动、异常处理、边界保护、资源抽离，以及和其他页面状态之间的配合。

比较稳的做法是分三步走：先把结构和职责立住，再把真实业务接进去，最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”，而是真的更接近可以长期维护的业务代码。

写在最后

animateTo 适合做轻量、明确、可恢复的反馈。点赞动画不要追求复杂，重点是让状态一致：图标、颜色、数量、文案都指向同一个结果。页面越小，越要把状态分干净。