用scroll事件无法直接触发@keyframes动画，应通过JS切换CSS类名（如.fade-in）来控制；推荐使用IntersectionObserver替代scroll监听，提升性能与兼容性，并注意动画重播、初始状态和fill-mode等细节。
用 scroll 事件直接触发 @keyframes 动画行不通
CSS 的 @keyframes 本身不能被 JavaScript 事件（比如 scroll）“调用”或“触发”。你没法写 element.animate(keyframes, options) 以外的方式让动画跑起来——而原生 CSS 规则里没有“监听滚动然后自动加动画类”这种机制。所以常见误区是试图在 scroll 回调里直接改 style.animation，但这样既难维护又容易冲突。
推荐做法：滚动时切换 class，靠 CSS 类控制动画
核心思路是把动画逻辑完全交给 CSS（用 @keyframes 定义），JS 只负责判断滚动位置、给元素加/删类名。这样解耦清晰，性能可控，也方便复用。
- 给目标元素预先定义一个带
animation的类，比如.fade-in - 用
IntersectionObserver替代手动监听scroll——更轻量、不卡顿、支持懒加载语义 - 避免在
scroll回调里反复操作 DOM 或计算getBoundingClientRect()
/* CSS */
@keyframes fadeIn {
from { opacity: 0; transform: translateY(20px); }
to { opacity: 1; transform: translateY(0); }
}
.fade-in {
animation: fadeIn 0.6s ease-out forwards;
}
/* 注意：不要在这里写 animation-delay 或依赖 JS 控制时机，延迟统一由 JS 添加类的时机决定 */
IntersectionObserver 比 scroll 事件更可靠
手动绑定 window.addEventListener('scroll', ...) 容易导致频繁触发、布局抖动、移动端兼容问题。而 IntersectionObserver 是浏览器原生的异步监听方案，只在元素真正进入视口时才通知，且可配置阈值（threshold）控制触发精度。
- 初始化时传入
{ threshold: 0.1 }表示元素 10% 进入视口就触发 - 回调中对每个
entry判断entry.isIntersecting，为真则添加动画类 - 记得调用
observer.unobserve(entry.target)避免重复触发（尤其是一次性动画）
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
entry.target.classList.add('fade-in');
observer.unobserve(entry.target);
}
});
}, { threshold: 0.1 });
document.querySelectorAll('.js-animate-on-scroll').forEach(el => {
observer.observe(el);
});
容易忽略的细节：动画重播与 CSS 层叠冲突
如果用户滚动回退，元素再次进入视口，默认不会重播动画——因为类已经存在，animation 不会二次触发。需要手动移除再加，或者用 animation-play-state 控制；但更稳妥的是用 animation-name: none 临时清空再恢复。
立即学习“前端免费学习笔记（深入）”；
- 不要用
transition+opacity替代@keyframes，它无法实现多阶段位移+透明度组合 - 确保目标元素初始状态（如
opacity: 0）和动画起始帧一致，否则第一帧会闪一下 - 若多个动画共存，注意
animation-fill-mode: forwards的影响——它会让动画结束后保留末帧样式，可能干扰后续交互
CSS 动画是否播放，取决于类是否存在；而类是否添加，取决于滚动时机是否被准确捕获。这两层必须分开设计，混在一起反而最难调试。
