应改用requestAnimationFrame插值实现数字跳动，因其与视图刷新同步、精度高；需记录起始时间按比例计算进度，配合缓动函数和卸载时cancelAnimationFrame清理，避免setInterval导致的卡顿跳变。

uni-app里用setInterval做数字跳动为什么卡顿或跳变？

App端（尤其是iOS）对setInterval的定时精度不敏感，且JS线程和原生渲染不同步，直接靠setInterval递增容易出现跳帧、卡顿、甚至目标值没到就停了。这不是代码写错了，是机制问题。

• 别用setInterval硬控步长，改用requestAnimationFrame驱动，它和视图刷新强绑定，更稳
• 起始值和目标值之间要按时间插值，不是简单加减——比如从0跳到1234，得算出每帧该显示多少，而不是每50ms+10
• 记得在组件卸载时清除动画帧，否则可能内存泄漏：cancelAnimationFrame必须配对requestAnimationFrame

uni-app中countTo组件在App端不生效的常见原因

很多开发者直接抄H5版countTo，但App端WebView内核（如WKWebView）对transform、will-change等CSS优化支持不一，导致动画掉帧或干脆不动。

• 确保目标元素有明确display: inline-block或display: block，避免文本节点被合并导致innerText更新失效
• 不要依赖CSS transition控制数字变化，App端文本内容变更不会触发transition，得靠JS重绘
• 如果用了uView或uni-ui的u-count-to，检查是否开启了useAnimation且animationDuration设得合理（建议300~800ms）

App端数字跳动如何兼容iOS和Android性能差异

iOS WKWebView默认禁用部分JS优化，Android（尤其低端机）JS执行慢但渲染快，同一套逻辑表现不一致。

• 用Date.now()记录起始时间，按「已过时间 / 总时长」算进度比用帧数更可靠
• 避免在跳动过程中频繁调用this.$forceUpdate()或修改响应式对象深层属性，优先用计算属性或watch配合immediate: true
• 数字位数多时（如带千分位），先格式化再渲染，但格式化逻辑不要放在render函数里——提成方法并加防抖，否则滚动中会卡

一个轻量可靠的App端数字跳动实现（无第三方依赖）

下面这段代码在uni-app 3.9+ App端实测稳定，支持暂停/重置/动态目标值：

export default {
  data() {
    return {
      currentValue: 0,
      targetValue: 0,
      startTime: null,
      duration: 600,
      animationId: null
    }
  },
  methods: {
    startCount() {
      this.startTime = Date.now()
      this.animationId = requestAnimationFrame(this.animate)
    },
    animate() {
      const elapsed = Date.now() - this.startTime
      const progress = Math.min(elapsed / this.duration, 1)
      // 缓动函数，比线性更自然
      const easeProgress = 1 - Math.pow(1 - progress, 3)
      this.currentValue = Math.floor(this.targetValue * easeProgress)
      if (progress < 1) {
        this.animationId = requestAnimationFrame(this.animate)
      }
    },
    reset() {
      cancelAnimationFrame(this.animationId)
      this.currentValue = 0
    }
  }
}

注意：如果targetValue中途变化，要先reset()再startCount()，否则插值逻辑会错乱。这点很容易被忽略，尤其在列表项中复用时。