transition 触发时元素“消失”或“错位”是因 opacity、transform、Filter 等属性创建新层叠上下文，导致 z-index 作用范围受限于该上下文而非全局，从而改变渲染顺序。
transition 触发时元素为什么突然“消失”或“错位”
不是 transition 本身让元素消失，而是它激活了新的层叠上下文（stacking context），导致 z-index 行为和渲染顺序发生意料外的变化。常见于对 opacity、transform、filter 做过渡时——这些属性只要一加，浏览器就立刻创建独立层叠上下文。
- 只要元素有
transform: translateZ(0)或will-change: transform，哪怕没动画，也会提前触发层叠上下文 -
z-index在子层叠上下文中只对同级兄弟有效；父容器的z-index不再“穿透”影响子元素的层叠顺序 - 如果过渡前元素靠
position: relative+z-index浮在其他内容上，一加transform过渡，它就可能被父容器的层叠层级“压住”
哪些 css 属性会悄悄创建层叠上下文并干扰 transition
不是所有过渡属性都安全。有些看似无害，实则会强制新建层叠上下文，进而改变整个区块的绘制顺序。最典型的是 transform 和 opacity，但容易被忽略的是 filter 和 isolation: isolate。
-
transform：哪怕只是translateX(0)，也会创建新层叠上下文 -
opacity：小于 1 的值（如opacity: 0.99）即触发，不只是0 -
filter：哪怕filter: blur(0)或filter: none（某些旧版 safari 中仍会） -
will-change：设为transform或opacity时，浏览器会提前创建层叠上下文，即使还没开始动画
如何验证某个元素是否意外进入了新层叠上下文
不能只看 DevTools 的 Styles 面板——它不直接标出“当前是否在层叠上下文中”。得靠渲染行为反推，或用更底层的调试手段。
- 打开 chrome DevTools → Rendering 面板 → 勾选 “Paint flashing”：层叠上下文边界会以绿色边框高亮（注意是“边界”，不是整个元素）
- 在 Elements 面板中右键元素 → “Show layer borders”：带橙色描边的图层即为独立层叠上下文
- 检查 computed 样式中是否有
contain: paint、transform、opacity 等触发条件，且该元素的 <code>z-index值非auto - 临时移除
transition，再逐个禁用可疑属性（比如注释掉transform），观察 z-order 是否恢复
想让 transition 不破坏渲染顺序，该避开哪些坑
核心思路不是“阻止层叠上下文”，而是控制它的范围和层级关系。强行避免 transform 会牺牲性能，也不现实。
立即学习“前端免费学习笔记（深入）”；
- 把需要交互的元素单独提一层 dom，用
position: absolute+ 明确的z-index定位，让它脱离原布局流的层叠依赖 - 若必须用
transform，就在其父容器也创建一个强层叠上下文（比如加transform: translateZ(0)），确保父子在同一层级体系内比较 z-index - 避免在
opacity过渡的同时还依赖z-index控制遮盖关系；改用visibility: hidden+transition: opacity组合更可控 - 慎用
will-change：它不会提升动画性能，反而常因过早创建层叠上下文引发渲染异常；只在真正卡顿且已确认是合成层瓶颈时才加
层叠上下文不是 bug，是 CSS 渲染模型的固有机制。问题往往出在“以为 z-index 全局有效”，而没意识到 transition 已经悄悄把你拖进了另一个绘制宇宙。