节流不直接优化显隐动画，而是防止高频事件触发导致动画逻辑冲突；应节流可见性检测而非动画执行，配合CSS transition和transitionend实现稳定过渡。
节流本身不直接优化显隐动画，而是防止因频繁触发（比如滚动、缩放）导致动画逻辑被反复重置或冲突。显隐过渡的核心是 CSS 控制，节流只是保障触发逻辑稳定可靠。
为什么显隐动画需要节流保护
显隐操作若绑定在 scroll、resize 或 mousemove 等高频事件上，可能在动画执行中途被重复调用，造成状态错乱：比如淡出动画刚到一半，又收到淡入指令，opacity 被强行设回 1，视觉跳跃；或多个 class 切换竞争，最终类名残留、动画中断。
节流的作用是“把一串密集触发，压成有间隔的几次有效响应”，确保每次动画都有完整执行窗口。
节流应加在触发判断环节，而非动画内部
正确做法是：只对“是否该显/隐”的决策做节流，而不是对 opacity 修改或 class 切换本身节流。动画过程必须连续，节流断在起点才合理。
立即学习“Java免费学习笔记（深入）”；
- 用 throttle 包裹元素可见性检测逻辑（如 isElementInViewport），而非 fadeIn() 函数
- 检测结果为 true 后，再调用无节流的 el.classList.add('fade-in')
- 避免在节流回调里写
el.style.opacity = ...或手动 requestAnimationFrame —— 这会破坏 CSS 过渡的原子性
推荐组合：节流 + CSS transition + transitionend 清理
一个健壮的滚动显隐方案包含三层：
- 节流层：每 60ms 最多检测一次元素是否进入视口（用 Lodash throttle 或自实现）
-
状态层：检测通过后，仅添加类名（如
.is-visible），由 CSS 定义opacity和visibility过渡 -
收尾层：监听
transitionend，动画结束后清理临时类或更新数据标记，避免下次触发误判
实际代码片段示意
假设监听页面滚动，让某个卡片淡入：
const card = document.querySelector('.card');
const observer = () => {
if (isInViewport(card)) {
card.classList.add('is-visible'); // 仅这一步，无节流
}
};
// 节流包装的是 observer，不是 addClass
const throttledObserver = _.throttle(observer, 60);
window.addEventListener('scroll', throttledObserver);
CSS 部分保持简洁：
.card {
opacity: 0;
visibility: hidden;
transition: opacity 0.4s ease, visibility 0.4s;
}
.card.is-visible {
opacity: 1;
visibility: visible;
}
