根本原因是浏览器将类添加与样式计算合并为同步操作，未产生状态差；需用 void el.offsetWidth 或 requestAnimationFrame 强制分帧，再配合 CSS transition 属性有效生效。
transition 为什么在 classList.add() 后不触发
根本原因不是 transition 写错了，而是浏览器把「添加类」和「计算新样式」合并成了一次同步操作，中间没留出过渡所需的“状态差”。classList.add() 本身不强制重排，如果紧接着又读取了 offsetHeight、getComputedStyle(el).width 这类布局属性，反而会打断过渡队列；但如果不做任何干预，浏览器可能直接跳到终态渲染。
用 void el.offsetWidth 强制触发重绘
这是最轻量、兼容性最好的手动重绘方式。它不改变 DOM，只让浏览器同步计算一次当前 layout，从而把初始样式“拍下来”，为后续 transition 留出起点。
- 必须在设置目标类之前执行，例如：
el.classList.remove('collapsed');<br>void el.offsetWidth; // ? 关键：制造 layout 闪断<br>el.classList.add('expanded'); - 不能用
clientWidth或scrollHeight替代，它们不一定触发重排；offsetWidth是最稳妥的选择 - 不要在循环里滥用，单次动画只需一次 —— 多次调用会引发重复 layout，卡顿明显
比 offsetWidth 更干净的替代方案：requestAnimationFrame
如果你已经用了现代写法（比如配合 Vue/React 的响应式更新），requestAnimationFrame 更语义清晰，且避免了对 layout 属性的副作用依赖。
- 典型结构：
el.classList.remove('collapsed');<br>requestAnimationFrame(() => {<br> el.classList.add('expanded');<br>}); - 原理是把 class 添加推迟到下一帧，确保上一帧已提交初始样式，浏览器自然识别出变化区间
- 注意：不能嵌套多层
requestAnimationFrame，否则延迟不可控；单层足够
容易被忽略的隐藏陷阱
即使加了重绘，transition 仍可能静默失败 —— 很多时候问题不在 JS 触发逻辑，而在 CSS 层面是否真正“活”着。
- 检查 DevTools 的 Computed 面板，搜索
transition，确认transition-property不是none、transition-duration不是0s - 父元素若设了
transform: translateZ(0)或will-change: transform，可能创建新层叠上下文，导致子元素过渡被截断（尤其在 Safari 中） - Unocss / Wind4 等原子化工具中，
transition类若未搭配duration-和ease-，变量未注入，生成的 CSS 里transition值实际为空
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
