JS 直接改 style 会覆盖 CSS transition 并丢弃过渡状态，根本解决法是确保起始值被浏览器明确识别：先显式设置初始样式（如 opacity、display），再通过 class 切换触发动画，而非依赖 requestAnimationFrame 掩盖初始化缺失。
JS 直接改 style 会覆盖 CSS 中定义的 transition，导致浏览器丢弃过渡状态，直接跳到新值——这不是 bug，是渲染机制决定的。想让过渡“重新生效”，关键不是加不加 requestAnimationFrame，而是**确保样式变更被拆到两个独立的渲染帧中执行**。
为什么 requestAnimationFrame 有时管用
它把 class 切换或 style 修改推迟到浏览器下一次重绘前，给了样式计算一个“空档期”。此时浏览器已将旧样式固化为起始态，再应用新样式时就能识别出“变化”，从而触发 transition。
- 常见错误写法：
el.classList.remove('fade');和el.classList.add('fade');连续执行，同属一帧 → 浏览器跳过中间态 - 加
requestAnimationFrame后，add 操作被推到下一帧 → 起始态（无类）和结束态（有类）被分隔开 - 但注意：如果元素刚插入 DOM 就立即调用
requestAnimationFrame，Firefox 下仍可能失败（它对帧时机更敏感）
比 requestAnimationFrame 更可靠的起始态固化方式
仅靠延迟不解决根本问题：浏览器需要明确知道“起始值是多少”。尤其当元素初始是 display: none 或未声明 opacity 时，requestAnimationFrame 也救不了。
- 先设可见性：
el.style.display = 'block'; - 强制重排以固化当前布局：
void el.offsetHeight;（或getComputedStyle(el).opacity） - 再设初始值：
el.style.opacity = '0'; - 最后加过渡类：
el.classList.add('fade-in');
哪些情况 requestAnimationFrame 反而会掩盖问题
它容易让人误以为“只要包一层就万事大吉”，但实际掩盖了样式声明缺失、属性未初始化、或内联样式覆盖等深层问题。
- 没定义初始
opacity，只靠.fade-in { opacity: 1; transition: opacity 0.3s; }→ 第一次加类依然无过渡 - 用了
element.style.transition = 'all 0.3s';后又切 class → 内联 transition 优先级更高，且不会随 class 移除自动清掉 - 监听
transitionend却没过滤属性名，结果transform和opacity各触发一次，逻辑错乱
真正要盯住的，从来不是“要不要加 requestAnimationFrame”，而是“起始值有没有被浏览器真正看见”——这取决于你是否显式声明了初始样式、是否避免了内联覆盖、以及是否在正确时机读取了计算样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
