opacity动画后元素仍占布局空间，因opacity仅影响透明度而不触发重排；需在动画结束后手动设置visibility:hidden或display:none来释放空间。
opacity 动画为什么元素“消失”后还占布局空间
用 opacity: 0 配合 @keyframes 实现淡入淡出，视觉上元素“不见了”，但实际它仍参与文档流，点击、鼠标悬停甚至无障碍阅读器都能感知到它。这不是 bug，是 css 规范行为——opacity 只影响渲染透明度，不触发重排（reflow），所以布局位置纹丝不动。
常见现象：动画结束后元素不可见，但下方内容没上移；或者想点按钮却点到了透明状态下的旧元素。
解决思路分两步走：
- 动画中保持
opacity变化，确保过渡自然 - 动画**完全结束**后，用 javaScript 或额外 CSS 规则把
visibility: hidden或display: none补上 - 若需重新显示，得先恢复
display或visibility，再触发动画（比如加 class）
用 animation-fill-mode 控制动画结束后的最终状态
animation-fill-mode 是关键控制点。默认值 none 意味着动画一停，元素立刻回退到动画前的样式；而设为 forwards 才能让最后一帧的样式（比如 opacity: 0）保留下来。
立即学习“前端免费学习笔记（深入）”；
但注意：forwards 只保留动画内声明的属性，它**不会自动加 visibility: hidden 或删掉元素**——这得你手动补。
示例片段：
@keyframes fadeOut { from { opacity: 1; } to { opacity: 0; } } .fade-out { animation: fadeOut 0.3s ease-in forwards; /* 动画停在 opacity: 0，但元素还在 */ }如果后续要彻底隐藏并释放空间，推荐配合 js 监听 animationend 事件：
el.addEventListener('animationend', () => { if (el.classlist.contains('fade-out')) { el.style.visibility = 'hidden'; } });交替播放时 class 切换容易漏掉 display/visibility 重置
做“显示 ⇄ 消失”循环动画时，常写两个 class：.show 和 .hide，靠 JS 切换来触发不同动画。最容易踩的坑是：切换前没清掉上一次留下的 visibility 或 display 内联样式，导致新动画被阻断或直接不生效。
安全做法是统一用 class 控制可见性 + 动画，避免混用内联样式：
-
.show：含visibility: visible; opacity: 1;+ 入场动画 -
.hide：含visibility: hidden; opacity: 0;+ 出场动画 - 切换前先移除旧 class，再添加新 class（或用
classList.toggle()配合条件判断）
特别注意：如果用 display: none 替代 visibility，那它和 opacity 不能共存于同一帧——display: none 会让元素瞬间从渲染树移除，opacity 动画直接中断。所以 display 只适合用在动画**结束后**，不能放在关键帧里。
性能与兼容性提醒：opacity 动画本身很轻量，但别滥用 will-change
opacity 是少数能被 GPU 加速的 CSS 属性之一，大多数现代浏览器对它优化得很好。不需要也不建议提前给元素加 will-change: opacity——这反而可能引发不必要的图层提升和内存开销。
真正要注意的是：
- IE 10+ 支持
opacity动画，但不支持animation-fill-mode: forwards（IE10–11 有 bug，动画结束后可能回退） - 移动端 safari 对快速连续触发的 opacity 动画偶有卡顿，建议加
transform: translateZ(0)强制硬件加速（仅当实测有问题时） - 如果元素内含大量子节点或复杂布局，即使 opacity 动画流畅，频繁切换 visibility 仍可能触发样式计算，此时应优先考虑是否真需要反复显示/隐藏，还是用更轻量的状态管理（如只更新内容）
最常被忽略的一点：动画时长和缓动函数必须匹配交互意图。0.1s 的 fadeout 看起来像闪退，0.8s 又拖沓。多数 ui 场景下，0.2–0.35s 配 ease-in-out 最自然。