JavaScript动画核心是requestAnimationFrame驱动、CSS控制视觉、数值插值决定中间态；因setTimeout/setInterval不同步刷新、无法暂停优化，易掉帧卡顿。
JavaScript 实现动画效果，核心不是靠“写一堆 setTimeout”，而是理解浏览器渲染机制和现代 API 的分工——用 requestAnimationFrame 驱动、用 CSS 属性控制视觉变化、用数值插值决定中间状态。
为什么不用 setInterval 或 setTimeout 做主循环？
它们不与屏幕刷新同步，容易掉帧、卡顿，且无法被浏览器优化或暂停（比如标签页切走时还在跑）。而 requestAnimationFrame 会自动对齐显示器的刷新节奏（通常是 60fps），并在页面不可见时暂停调用。
常见错误现象：setTimeout(..., 16) 看似想模拟 60fps，但实际执行时间不可控，叠加 JS 执行延迟后，帧率波动大，动画抖动明显。
- 必须用
requestAnimationFrame替代定时器作为主循环入口 - 每次回调中只做「计算 + 更新样式」两件事，避免重排（
layout）或长任务 - 手动记录上一帧时间戳，用差值做匀速/缓动判断，别依赖固定间隔
requestAnimationFrame 怎么配合数值插值做缓动动画？
动画本质是「从 A 值到 B 值，在 T 时间内按某种节奏过渡」。浏览器不管节奏，只负责渲染；JS 负责算出每一帧该取什么值。
立即学习“Java免费学习笔记（深入）”；
示例：把一个 div 的 left 从 0px 动到 200px，持续 500ms，使用 ease-out 缓动：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
let start = null;
const duration = 500;
const from = 0;
const to = 200;
<p>function animate(timestamp) {
if (!start) start = timestamp;
const progress = Math.min((timestamp - start) / duration, 1);
const eased = 1 - Math.pow(1 - progress, 3); // ease-out cubic
const value = from + (to - from) * eased;
element.style.left = value + 'px';
if (progress < 1) requestAnimationFrame(animate);
}
requestAnimationFrame(animate);关键点：
- 缓动函数（如
easeOutCubic）决定的是 progress → eased 的映射，不是直接操作 DOM - 务必用
timestamp计算真实经过时间，而非帧数计数，否则变速/跳帧时会失准 - 不要在动画循环里读取
offsetLeft等触发重排的属性
CSS 动画和 JS 动画该选哪个？
不是“谁更好”，而是“谁更适合当前场景”：
- 纯视觉位移/缩放/透明度变化 → 优先用
transform+transition或@keyframes，GPU 加速、性能好、代码少 - 需要动态响应用户交互（如拖拽中实时跟随鼠标）、或依赖 JS 运行时数据（如滚动进度驱动视差）→ 必须用
requestAnimationFrame - 要精确控制暂停/回放/时间轴（如播放进度条拖动）→ 用 JS 管理状态，CSS 只负责最终样式
混用常见坑：transition 和 JS 同时修改同一属性（如都改 opacity），会导致行为冲突或意外中断。
动画卡顿的三个隐蔽原因
很多卡顿不是因为“动画太复杂”，而是触发了低效路径：
- 修改
top/left等触发 layout 的属性 → 改用transform: translateX() - 频繁读写同一元素的样式（如先
getBoundingClientRect()再改style）→ 把读操作批量前置，写操作批量后置 - 动画元素没开启硬件加速 → 加
transform: translateZ(0)或will-change: transform（慎用，仅对长期动画元素）
真正难的不是让东西动起来，而是让动得稳、停得准、切页时不偷跑——这些细节藏在每一帧的计算和样式更新之间。
