仅用 opacity 淡出会显得“假”，因元素仍占布局空间、可能响应点击、缺乏位移缩放等物理反馈，易导致抖动或卡顿；需配合 transform、pointer-events、animationend 事件及合理 DOM 清理才能实现自然退场。
为什么只用 opacity 淡出会显得“假”
单纯把 opacity 从 1 变到 0，视觉上只是“变透明”，但元素还在原位、仍占空间、甚至可能意外响应点击。用户会觉得消息“卡了一下才走”，尤其在密集弹出时更明显。
- 浏览器不会自动释放布局空间，
opacity: 0后若没配pointer-events: none，鼠标悬停仍可能触发伪类 - 没有位移或缩放变化，缺乏“离开感”，和真实物理反馈脱节
- 若容器用
height或max-height控制展开，仅改opacity会导致内容区域突然塌陷，出现抖动
用 @keyframes 做带缩放的淡出动画
比 transition 更可控：能精确控制起始/结束状态，且支持多属性同步变化。关键不是炫技，而是让消失有“收尾动作”。
- 动画必须加
forwards，否则结束后opacity和transform会回退到初始值 - 缩放建议微调（如
scale(0.98)），避免夸张变形影响可读性 - 配合轻微上移（
translateY(-4px)）能强化“飘走”感，又不破坏节奏
@keyframes fadeOutWithShrink {
from { opacity: 1; transform: scale(1) translateY(0); }
to { opacity: 0; transform: scale(0.98) translateY(-4px); }
}
.toast--fading {
animation: fadeOutWithShrink 0.3s ease-out forwards;
}
动画结束后的 DOM 清理不能靠 setTimeout
setTimeout 看似简单，但一旦动画时长被 CSS 自定义变量或媒体查询覆盖，就容易提前删 DOM，导致动画中断或报错。
- 必须监听
animationend事件，并校验e.animationName === 'fadeOutWithShrink' - 添加动画类前，先设
pointer-events: none，防止动画中途被点击干扰 - 清理前检查元素是否还存在于 DOM 中（避免重复触发或已移除后调用
remove()）
toastElement.classList.add('toast--fading');
toastElement.style.pointerEvents = 'none';
toastElement.addEventListener('animationend', (e) => {
if (e.animationName === 'fadeOutWithShrink') {
toastElement.remove();
}
});
通知组件的定位与过渡兼容性陷阱
用 position: fixed 的通知，若父容器有 transform、filter 或 will-change，会创建新的层叠上下文，导致 z-index 失效或过渡闪烁。
立即学习“前端免费学习笔记（深入）”；
- 确保通知直接挂载在
document.body下，绕过中间层叠污染 - 不要对通知元素本身设
transform: translateZ(0)之类强制硬件加速——现代浏览器对opacity + transform动画已默认 GPU 加速，额外声明反而可能触发重绘 - IE11 不支持
animationend，需降级为webkitAnimationEnd和oAnimationEnd，但 2026 年多数项目已无需兼容
pointer-events、层叠上下文和事件监听的组合里。 
