opacity动画初始不可见需预设CSS初始值，transition须写在原始样式中而非伪类里，配合visibility:hidden可彻底隐藏，避免FOUC应初始HTML加class并用requestAnimationFrame切换。
opacity 动画为什么一开始看不见元素
直接给元素设 opacity: 0 再加 transition，常出现“元素突然闪一下才开始淡入”——这是因为浏览器默认把 opacity: 0 的元素仍参与布局、但未触发重绘时机。更关键的是，如果元素初始状态没在 CSS 中明确定义（比如只靠 JS 后续设置），transition 就无法捕获起始值，动画直接跳到终点。
实操建议：
- 必须在 CSS 中预先声明初始
opacity值，例如：.fade-in { opacity: 0; transition: opacity 0.3s ease; } - 配合
visibility: hidden控制是否占位：仅用opacity元素仍响应事件、占布局空间；加visibility: hidden可彻底隐藏交互与占位，但需同步控制两者的过渡时序 - 避免在 JS 中用
element.style.opacity = "0"覆盖 CSS 初始值，改用 class 切换更可靠
transition 要写在哪个选择器里才生效
transition 必须写在**状态变化前的原始样式规则中**，而不是只写在 hover 或 active 等伪类里。否则浏览器不会为属性变化准备过渡逻辑，结果就是瞬间切换。
常见错误写法：.box:hover { opacity: 1; transition: opacity 0.3s; } → hover 进入有动画，但鼠标移出时 opacity 立即回退到 0
立即学习“前端免费学习笔记（深入）”；
正确写法：
.box {
opacity: 0;
transition: opacity 0.3s ease;
}
.box.show {
opacity: 1;
}
这样无论 class 是通过 JS 添加还是移除，进出都有平滑过渡。
为什么加了 transition 还是卡顿或不触发
不是所有属性变化都能被硬件加速，opacity 是少数天然支持 GPU 加速的属性之一，但前提是它没被其他低效操作拖累。
容易踩的坑：
- 父容器有
transform: scale(1)或will-change: transform之类声明，可能干扰子元素 opacity 的合成层判断 - 元素本身有
position: absolute但父级没形成 stacking context，导致 opacity 变化时重排范围扩大 - 在移动端 Safari 上，若元素含
backface-visibility: hidden，有时会意外禁用 opacity 过渡（尤其配合transform时） - 过渡时间太短（如
0.05s）或太长（如2s），人眼感知异常，误以为“没动”
JS 控制显示时如何避免 FOUC 和竞态
页面加载后 JS 才添加 show class，用户可能先看到空白再淡入——这就是 FOUC（Flash of Unstyled Content）。更糟的是，若 JS 执行慢于 CSS 解析，或多个脚本并发操作同一元素 class，会出现动画中断、反复触发。
稳妥做法：
- 初始 HTML 中就带
class="fade-in"，CSS 定义.fade-in { opacity: 0; }，JS 只负责加show类，不负责初始化 - 用
requestAnimationFrame包裹 class 切换，确保在下一帧执行：requestAnimationFrame(() => el.classList.add('show')) - 需要批量处理多个元素时，避免逐个调用
el.classList.add，改用el.setAttribute('class', 'fade-in show')防止重复重排
真正难的不是写对那两行 CSS，而是让 opacity 过渡在各种 DOM 注入时机、嵌套层级和浏览器渲染节奏下都稳定生效。稍不注意，就会变成“看起来写了，实际没动”。
