根本原因是浏览器在单次渲染帧内合并classList.remove()和add()操作，未触发动画重播；需用void el.offsetHeight强制重排来中断渲染流水线，确保动画正确重启。
浏览器没“看见”类被移除过
根本原因不是 JS 没执行，而是浏览器在单次渲染帧内合并了 classList.remove() 和 classList.add() 两个操作。它只记录“这个元素最终有动画类”，不认为中间存在“无动画”的状态，所以不会重置动画时间轴。
典型错误写法：
el.classList.remove('bounce');
el.classList.add('bounce'); // 同步执行 → 动画不重播
- 即使 DOM 看似更新了，
getComputedStyle(el).animationName可能仍返回原值，说明浏览器未触发新动画实例 - 该问题在 Chrome、Firefox、Safari 中一致存在，不是兼容性 bug，而是渲染机制使然
- 用
console.log(el.classList)看不出问题，因为 class 列表确实变了——但浏览器样式引擎不靠这个判断动画是否重启
animation-fill-mode: forwards 会锁死终态
如果动画结束时用了 animation-fill-mode: forwards，元素会永久保留最后一帧的样式（比如 transform: translateY(100px)）。此时哪怕你清空 class 或重设 animation-name，这些残留样式仍会覆盖新动画的初始帧，导致视觉上“跳变”或“不动”。
- 必须确保动画类中显式声明
animation-fill-mode: none或backwards，避免终态污染 - 若需终态保留，应在动画结束后用 JS 手动设置对应样式，而不是依赖
forwards - 不要在同一个元素上混用 JS 设置的
el.style.transform和 CSS 动画里的transform，冲突时动画大概率不触发
强制重排（reflow）是最小代价的解法
让浏览器“感知状态变化”的最轻量方式是触发同步布局计算，void el.offsetHeight 是目前最稳定的选择——它不改变任何样式，只迫使浏览器立即读取当前布局，从而中断渲染流水线，为下一次 class 添加创造干净起点。
可靠写法：
function replayAnimation(el, className) {
el.classList.remove(className);
void el.offsetHeight; // 关键：强制重排
el.classList.add(className);
}
- 不能用
setTimeout(..., 0)替代重排：异步延迟无法保证渲染时机，某些 Android WebView 下仍失败 - 不能用
getComputedStyle(el).opacity等非布局属性：部分浏览器不触发 reflow，iOS Safari 尤其敏感 - 若元素
display: none，此方法无效；需先设为block或visible再调用
visibilitychange 或 display 切换后动画不播
元素从隐藏变为可见时动画失效，本质是动画已在隐藏期间“悄悄跑完”。浏览器不因 visibility 或 display 变化而重置动画状态，哪怕你手动加 class 也一样——除非中间插入重排。
- 监听
visibilitychange时，必须三步走：remove → offsetHeight → add，缺一不可 - 移动端要兜底
pageshow和focus事件，iOS Safari 的visibilitychange延迟可达 500ms - 动画时长低于
0.15s在部分 Android Webview 中会被跳过首帧，建议底线设为150ms
真正卡住人的从来不是“怎么写”，而是忘了重排那一步——它不报错、不警告，只是静默失效。只要元素还在文档流里，offsetHeight 就是最值得信赖的扳机。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
