应使用 requestAnimationFrame 替代 setTimeout 实现平滑动画，配合预加载图片（new Image() + onload）、避免复用实例、用 opacity/visibility 控制切换，并通过 picture 或服务端适配 WebP 等格式。
用
替代
做平滑动画
直接改
配合
看似简单，但容易卡顿、掉帧，尤其在低端设备或后台标签页里。浏览器对
有优化，能自动对齐屏幕刷新率，且在页面不可见时会暂停调用——这是它比轮询更靠谱的根本原因。
别用
或高频
（比如
），它们不保证执行时机，还可能堆积回调
每次动画帧只做一件事：计算下一帧该显示哪张图，然后赋值给
，不要在里面加 DOM 操作或网络请求
如果图片已缓存，切换几乎无延迟；若未缓存，
赋值后需监听
才能确保渲染，否则可能闪白或跳帧
预加载图片避免动画中断
动态切换时突然卡住一两帧？大概率是下一张图还没加载完。
赋值那一刻才开始请求，而动画已经跑起来了。必须提前把所有图片实例创建好并触发加载。
用
创建图片对象，立刻赋值
，不用插入 DOM
等所有
触发后再启动动画循环，否则第一轮就可能 fallback 到空白
注意：不要复用同一个
实例反复改
，部分浏览器会中止前一个请求；每个地址配一个独立实例更稳
示例关键片段：
用 CSS
或
避免重排重绘
如果动效需要淡入淡出、叠加切换，直接换
会导致硬切。此时不该靠 JS 搞多个
标签来回 show/hide——那样触发 layout，性能差。
用两个
标签叠在一起，靠
和
做交叉淡化，JS 只控制 class 切换
确保父容器设了
，子图设
+
慎用
切换，它会触发重排；
更轻量，但依然占布局空间
处理 WebP/AVIF 等现代格式的兼容性 fallback
想用更小体积的
做动画？别直接写死后缀。用户浏览器不支持时，
会挂掉，动画就停在半路。
php版微信js-sdk支付接口类
php版微信js-sdk支付接口类
下载
立即学习
“
前端免费学习笔记（深入）
”；
用
+
是标准解法，但注意：JS 动态切换时，不能只改
，得同步更新
内的
更简单的方案：服务端根据
请求头返回对应格式，前端统一用
后缀，实际响应可能是 WebP
本地开发时，Chrome 可能缓存失败的 WebP 请求，导致后续一直 fallback，清空缓存或用无痕模式验证
真正麻烦的不是怎么播，而是怎么让每一张图都在该出现的时候「已经躺在内存里」——预加载漏一张，动画就露馅一次。
requestAnimationFramesetTimeoutimg.srcsetTimeoutrequestAnimationFramesetIntervalsetTimeoutsetTimeout(..., 16)img.srcimg.srconloadimg.srcnew Image().srconloadImagesrcconst frames = ['a.png', 'b.png', 'c.png'].map(src => {
const img = new Image();
img.src = src;
return img;
});
Promise.all(frames.map(img => new Promise(r => img.onload = r))).then(startAnimation);opacityvisibilityimg.srcimgopacitytransitionposition: relativeposition: absolutetop: 0; left: 0display: nonevisibility: hidden.webpimgpicturesourceimg.srcpicturesource[srcset]Accept.png