网页动画选原生CSS还是JS控制

先分清动画的驱动方式

CSS动画和JavaScript驱动的动画，本质区别不在“谁写的代码”，而在“谁在每一帧决定元素的状态”。

CSS动画（transition和@keyframes）由浏览器合成器直接处理，声明了起点和终点，中间过程交给渲染引擎。适合“状态切换”类动效：按钮悬停变色、菜单展开收起、卡片淡入上移。这类动画触发条件明确，不需要中途读取数据或改变方向，CSS声明式写法最省。

JavaScript控制的动画，每一帧都由脚本计算并更新属性。适合“状态依赖逻辑”的动效：滚动位置决定进度条长度、鼠标坐标影响视差位移、多元素交错入场需要计算延迟。还有Canvas和WebGL这类脱离DOM的绘图场景，CSS根本管不了。

判断标准可以简化成两个问题：动画过程是否需要读取外部状态？是否需要在中途暂停、反向或跳转？如果都不需要，CSS优先；只要有一个需要，就要考虑JS。

CSS能覆盖的常见范围

CSS动画适合的典型场景包括：悬停反馈、焦点状态变化、元素显隐过渡、简单的循环强调效果。

实现时优先用transform和opacity做动画属性。这两个属性不触发布局和绘制，合成器可以直接处理，性能最稳。修改width、height、top、left这类属性会触发布局计算，在低端移动设备上容易出现掉帧。

另一个容易忽略的点是transition的触发条件。transition只在属性值发生变化时生效，元素首次渲染时不会播放过渡。如果希望元素加载时就有入场动画，要用@keyframes配合animation属性，而不是transition。

@keyframes可以定义多个关键帧位置，适合稍微复杂的路径动画。但要注意，CSS动画的中间帧由浏览器插值生成，如果动画过程需要“先加速后减速再弹跳”这类自定义节奏，可以用cubic-bezier曲线或内置的ease-in-out等缓动函数表达。内置缓动不够用时，才考虑用JS库提供更丰富的缓动曲线。

JavaScript介入的时机

当动画状态需要和页面数据联动，CSS就力不从心了。

典型场景是滚动驱动的动画。页面滚动位置是一个持续变化的数值，CSS无法直接读取这个值来决定动画进度。需要用JavaScript监听滚动事件，计算元素进入视口的位置，再动态设置样式或触发类名切换。这里要注意，滚动事件触发频率很高，直接在事件回调里写样式更新会造成性能压力，通常需要用requestAnimationFrame做节流，把更新操作合并到每一帧只执行一次。

另一个场景是多个元素需要按顺序交错入场。CSS可以给每个元素设置不同的animation-delay，但如果元素数量是动态的，或者入场顺序由数据决定，用JavaScript循环控制更灵活。

Canvas动画基本只能走JavaScript。Canvas本身是一个绘图表面，没有DOM节点，不存在CSS可以作用的元素。每一帧都需要脚本计算图形位置并重绘。这类动画适合粒子效果、数据可视化、游戏画面。实现前要确认Canvas的绘图循环是否能稳定跑在目标设备的帧率上，必要时降级为静态图或减少粒子数量。

代码示例：一个滚动触发的入场动画

假设页面里有一组卡片，希望它们滚动到视口内时依次淡入上移。CSS负责定义动画本身，JavaScript只负责在正确的时机触发类名。

```css
.card {
opacity: 0;
transform: translateY(20px);
transition: opacity 0.4s ease, transform 0.4s ease;
}

.card.visible {
opacity: 1;
transform: translateY(0);
}
```

```javascript
const cards = document.querySelectorAll('.card');

function checkPosition() {
cards.forEach((card, index) => {
const rect = card.getBoundingClientRect();
if (rect.top < window.innerHeight && !card.classList.contains('visible')) {
// 用延迟制造依次出现的效果
setTimeout(() => card.classList.add('visible'), index * 80);
}
});
}

window.addEventListener('scroll', checkPosition);
checkPosition(); // 页面加载时先检查一次
```

这段代码里CSS只负责过渡，JavaScript负责判断元素位置并添加类名。需要注意的边界情况是：如果用户使用键盘Tab键导航而不是滚动鼠标，scroll事件不会触发，卡片可能一直不可见。这时需要在元素获得焦点时也执行一次检查，或者用IntersectionObserver替代scroll监听，它能在元素进入视口时自动回调，对键盘导航和屏幕阅读器更友好。

性能与降级策略

动画性能问题通常出在持续运行的动画上。CSS动画如果设置了无限循环，即使页面不可见也在消耗资源。可以用prefers-reduced-motion媒体查询检测用户系统是否开启了“减少动态效果”的辅助设置，如果开启，就关闭装饰性动画，只保留必要的状态反馈。

移动端的处理原则是减少同时运动的元素数量。多个元素同时做位移动画，即使每个都很轻量，叠加起来也可能让低端设备掉帧。可以把动画拆成几组，错开时间，或者降低动画位移距离。

另一个常见问题是动画和页面布局的耦合。如果动画过程中改变了元素尺寸，后续元素的位置会跟着跳动，视觉上很乱。解决方法是给动画元素预留固定空间，或者用transform做视觉位移而不影响文档流。

检查与验收方法

动画实现完成后，检查分三个层面。

第一层是功能检查：动画是否在预期条件下触发，是否完成了状态切换。第二层是性能检查：打开浏览器开发者工具的性能面板，录制一段包含动画的操作，观察帧率是否稳定在目标范围内，有没有长时间的脚本执行阻塞。第三层是适配检查：在窄屏设备上确认动画没有导致横向滚动，文字没有因动画位移被截断，键盘操作时焦点状态依然清晰可见。

如果动画在低端设备上表现不佳，优先检查是否使用了触发布局的属性，其次减少同时运动的元素数量，最后才考虑用JavaScript重写。多数情况下，问题出在动画数量过多或属性选择不当，而不是CSS本身能力不足。

选择实现方式时，先写一个最小可用的版本，确认动画逻辑正确后再考虑优化。动画逻辑本身有误时，换用任何技术栈都救不回来。