能用，但需绕开iOS微信WebView对transform:scale()的兼容问题；应改用width/height+opacity组合实现红心点击动画，并通过$nextTick切换class强制重播，避免animation-fill-mode失效及JS桥接性能损耗。
uni-app里怎么用@keyframes做收藏红心点击动画
直接上结论：能用，但得绕开transform: scale()在iOS微信WebView里的兼容问题。uni-app本身不拦截CSS动画，问题出在底层WebView对transform硬件加速的处理差异，尤其iOS 14–15的微信内嵌浏览器常出现缩放卡顿或不触发。
实操建议：
- 用
width/height+opacity组合替代scale()，虽略失真但稳定 - 动画时长控制在
0.25s以内，避免微信JS线程阻塞导致点击反馈延迟 - 必须给
<view class="heart">加display: inline-block，否则width动画在部分Android机型上无效
@keyframes heart-bounce {
0% { width: 20px; height: 20px; opacity: 0.7; }
50% { width: 28px; height: 28px; opacity: 1; }
100% { width: 20px; height: 20px; opacity: 0.9; }
}
uni-app中click事件触发后如何重置动画
常见错误是只改class，但CSS动画不会自动重播——因为DOM没变，浏览器跳过重绘。必须强制“打断”动画流。
正确做法（Vue 2/3均适用）：
立即学习“前端免费学习笔记（深入）”；
- 用
this.$nextTick()确保DOM更新完成后再切换class - 先移除动画class，再
$nextTick后加回，触发重播 - 别用
setTimeout延时，uni-app的createSelectorQuery在某些低端机上会延迟
toggleHeart() {
this.isCollected = !this.isCollected;
this.heartClass = 'heart';
this.$nextTick(() => {
this.heartClass = 'heart animated';
});
}
为什么animation-fill-mode: forwards在uni-app里经常失效
不是写法错，是uni-app的style绑定机制和WXSS编译顺序冲突。当用:class动态切class时，forwards会被覆盖为初始状态。
绕过方案：
- 把最终态样式单独抽成一个class（比如
.heart-collected），不在keyframes里定义终值 - 动画只负责“动”的过程，静止状态由class控制
- 避免在同一个元素上同时用
animation和transition，uni-app的rpx转换可能让两者时序错乱
真机调试时动画卡顿，该查哪几处
重点看三个地方：
- 是否在
watch或computed里频繁触发forceUpdate——每次都会清空CSS动画队列 -
background-image用了base64大图？iOS微信会因解码阻塞主线程，动画直接掉帧 - 有没有在
onPullDownRefresh里没uni.stopPullDownRefresh()？持续下拉会锁住渲染线程
最隐蔽的坑：用uni.createAnimation() API做同效果，反而比纯CSS慢——它走的是JS桥接，比原生CSS动画多2~3层调用栈。
