应使用 intersection observer 替代手动 scroll 检测，结合防抖控制动效触发，避免重排重绘与内存堆积；css 动效用 transform + opacity 并合理设置 will-change。
移动端 H5 长列表滚动时，卡片进出场动效（比如淡入、上滑入场、缩放等）若不加控制，极易因频繁触发而引发卡顿：每次 scroll 事件都读取元素位置、判断是否进入视口、执行 CSS 动画或 JS 动画逻辑，会大量触发重排重绘，甚至造成内存堆积。节流与防抖不是直接用来“优化动效本身”，而是用来**约束动效触发的时机和频率**，避免无效、重复、冲突的动效计算和渲染。
一、明确节流 vs 防抖的适用场景
对卡片动效而言，核心判断逻辑是：“这个卡片当前是否在可视区域内？” 这个判断需要读取 DOM 布局（如 getBoundingClientRect），属于高成本操作，必须节流；而动效的启动（如加 class 触发 CSS transition）本身应“只执行一次”，适合防抖式去重。
-
节流用于“检测”：滚动中持续检查卡片是否进入/离开视口，但不必每帧都算——用
throttle(..., 60ms)或requestAnimationFrame控制检测频率，保证每秒约 16 次即可匹配 60FPS。 - 防抖用于“触发”：同一张卡片在短时间内反复进出视口（如快速来回滚动），应确保它只“入场一次”“离场一次”。可用防抖包裹动效执行逻辑，延迟 100–200ms 执行，期间再次进入则重置计时。
二、推荐实现：RAF + 节流检测 + 防抖动效
比单纯用 setTimeout 节流更优的是结合 requestAnimationFrame，它天然对齐浏览器刷新节奏，避免丢帧：
- 监听
scroll时启用{ passive: true }，防止阻塞滚动线程； - 在
requestAnimationFrame回调里批量读取所有待监测卡片的位置（避免 layout thrashing）； - 对每张卡片的状态变更（in → out / out → in）做防抖：仅当状态真正稳定后（比如停留超 100ms），才添加
animate-in或animate-outclass； - CSS 动效统一用
transform+opacity，并加will-change: transform, opacity（滚动开始前设置，结束 100ms 后移除）。
三、避免常见陷阱
这些细节看似小，却是 iOS 卡顿、Android 白屏的高频诱因：
-
别在 scroll 里直接调
getBoundingClientRect()：它强制同步布局，单次调用就可能耗时数毫秒。应先缓存容器尺寸、滚动偏移，再用相对计算代替； - 不要给每个卡片单独绑定 scroll 监听器：统一由列表容器监听，用 Intersection Observer 替代手动计算（兼容性已足够：iOS 13.4+、Android Chrome 51+）；
-
动效 class 不要靠 JS 反复 toggle：用数据驱动（如
isInViewport状态），配合 Vue/React 的响应式更新，避免重复 DOM 操作； - 虚拟滚动下慎用进场动效：若已用虚拟滚动（只渲染可视区域），卡片 mount/unmount 本身已是“自然进出”，额外加动效反而增加 CPU 开销，建议仅对首屏或关键卡片启用。
四、轻量级代码示意（无框架）
以下为可直接落地的核心逻辑片段：
const observer = new IntersectionObserver(
(entries) => {
entries.forEach(entry => {
const card = entry.target;
// 防抖：确保状态稳定后再更新
clearTimeout(card._animTimer);
card._animTimer = setTimeout(() => {
if (entry.isIntersecting) {
card.classList.add('animate-in');
} else {
card.classList.remove('animate-in');
}
}, 120);
});
},
{ threshold: 0.1, rootMargin: '50px' } // 提前 50px 触发入场
);
// 对每个卡片调用 observer.observe(card)
Intersection Observer 自带节流能力，无需额外封装，且不阻塞主线程，是目前最稳妥的方案。
