u-count-to动画一闪而过最常见原因是只传end-val而漏掉start-val或duration；必须三者同为Number类型、显式声明，decimals需匹配end-val小数位，小程序中须用$nextTick+createSelectorQuery获取节点。
u-count-to 参数配错会导致动画一闪而过
最常见问题是只传 end-val，漏掉 start-val 或 duration。组件默认 duration 是 300ms，数值大时根本看不出滚动过程。
必须确保三者类型一致且显式声明：
-
start-val和end-val都要是Number，字符串如"1200"会触发NaN -
duration必须是数字，写成"500"会导致内部计算异常 - 要保留小数，
decimals得匹配end-val实际位数，比如end-val="899.6"就得设decimals="1" - 小程序里
autoplay默认为true，但数据常在onLoad后异步到达，建议先设autoplay="false"，等this.$nextTick()后再调this.$refs.uCountTo.start()
countUp.js 在小程序报 target is null
这不是代码写错了，是 uni-app 渲染时机和 DOM 节点可用性不一致导致的。直接在 onLoad 里 new CountUp()，节点还没挂载，querySelector 返回 null。
正确做法分两步：等渲染完成 + 拿到真实可操作节点：
- 用
this.$nextTick()确保 Vue 模板已更新 - H5/APP 端可直接用
document.getElementById；小程序端必须走uni.createSelectorQuery().in(this)，且加.fields({ node: true }) - 拿到
res.node后不能直接传给原版countUp.js—— 它不认小程序虚拟节点。要么换用适配版（如countup-weapp），要么降级为手动requestAnimationFrame更新innerText
手写 requestAnimationFrame 滚动时数字超纲或跳帧
自己实现看似自由，但两个坑极易踩中：一是结束判断逻辑错，二是帧调度被干扰。
关键细节：
- 别用
current >= end判断结束，要用elapsed >= duration。帧率波动时，某帧可能算出略超end的值，导致多执行一帧、数字“蹦高” - 缓动函数输出后必须四舍五入再赋值给
data，否则小数累积会让视图抖动（尤其带decimals="0"时） - 避免把滚动组件塞进
scroll-view。一旦父容器启用scroll-with-animation或频繁触发@scroll，会抢占requestAnimationFrame的调度权，出现卡顿、跳数 - 单位（如 “万”、“亿”）别塞进滚动逻辑，应在模板外用计算属性拼接，否则缓动过程中单位跟着闪
separator 和 use-easing 不是锦上添花，而是体验底线
大屏数据滚动不是炫技，用户扫读效率和信任感直接受这两个参数影响。
-
separator=","不只是“好看”，人眼识别"1,245,678"比"1245678"快 30% 以上；某些旧版支付宝小程序不支持千分位，需 fallback 到正则格式化：String(num).replace(/\B(?=(\d{3})+(?!\d))/g, ",") -
use-easing关乎信任感：匀速滚动像计数器，缓动收尾才像真实数据增长。开启后最后 20% 时间内速度明显放缓，用户能看清最终数值
真机调试时最容易忽略的，是节点挂载时机与跨端 API 差异——H5 可直接操作 DOM，小程序却要绕一层 query，App 端又得加 .in(this)。这些不是配置问题，是渲染链路里的确定性瓶颈。
