CSS 的 z-index 在框架中更难预测，因组件化 DOM 被拆分但层叠仍全局计算；父组件的 transform、opacity 等会创建新层叠上下文，使子组件 z-index 失效；应检查层叠上下文、统一锚点至根节点、禁用自由 z-index 值、确保 Portal 挂载到无层叠上下文的节点（如 body），并用 DevTools 快速定位阻断源。
为什么 CSS 的 z-index 在框架里反而更难预测？
因为框架（尤其是 React/Vue 组件化结构）天然拆分了 DOM 作用域，但 z-index 仍按全局层叠上下文计算——组件内部设了 z-index: 999，可能被父组件一个 transform 或 opacity: 0.99 拦腰截断，直接降级成局部层叠上下文，数值再大也出不去。
实操建议：
- 不要在组件内部盲目堆高
z-index，先用浏览器开发者工具检查该元素是否已处于新的层叠上下文（Elements 面板看 Computed → “Layer” 或 “Stacking context”） - 若需跨组件控制层级（如弹窗盖过导航栏），把关键层叠锚点统一提至 App 根节点附近，例如用
div#app > .overlay-container做唯一出口 - 避免用
position: relative+z-index无意义地“占位”，它可能意外创建层叠上下文，尤其在React.memo或v-if切换频繁的区域
Bootstrap/Tailwind 这类框架怎么悄悄改写你的层叠逻辑？
它们不是“帮你管层级”，而是通过预设 class 强制约定层级范围。比如 Tailwind 的 z-0 到 z-50 是线性映射，但一旦你在自定义样式里写 z-index: 9999，就脱离了这套体系——后续维护者无法靠 class 名判断相对高低，协作时极易冲突。
实操建议：
- 禁用自由数字型
z-index值，全部走框架提供的语义化层级 class（如z-10、z-[100]） - Tailwind 中启用
z-index插件时，注意其默认配置上限是z-50，要扩展必须显式修改theme.extend.zIndex，否则z-51不生效 - Bootstrap 5 的
.modal默认z-index: 1055，但它依赖$zindex-modal-backdrop: 1050等 SASS 变量联动，直接覆盖 CSS 会破坏 backdrop 和 modal 的相对关系
Vue/React 组件中动态插入的弹层，为何总被“吃掉”？
常见现象：点击按钮后 createPortal 或 Teleport 渲染的弹窗，依然显示在底层——问题往往不在弹窗本身，而在它的挂载容器（如 #portal）位于某个有层叠上下文的父容器内，导致整个 portal 子树被“框死”。
实操建议：
-
Teleport必须挂载到根级无层叠上下文的节点，推荐document.body，而非document.getElementById('app')（Vue 应用根节点常带transform） - React 中用
createPortal时，确保目标容器未设置will-change、filter、opacity 等触发层叠上下文的属性 - 若必须挂载到非 body 节点，可在该容器上加
isolation: isolate主动创建独立层叠上下文，让其子树重新获得“全局感”
怎样用最少改动验证当前页面的层叠瓶颈？
不用重写样式，先定位哪一层“卡住”了你。打开 DevTools → Elements → 选中目标元素 → 右侧 Styles 面板搜索 z-index，再切换到 Computed 标签页，拉到底部看 “Stacking Context” 是否为 “Yes”。如果是，往上逐级检查父元素的 transform、opacity、filter、will-change、contain 等属性。
快速验证步骤：
- 临时给疑似“卡层”的父容器加
outline: 2px solid red，确认是否真为阻断源 - 在 Console 执行
getComputedStyle(el).getPropertyValue('z-index')查真实计算值（注意auto表示未参与层叠排序） - 对关键节点执行
el.closest('*:has(> .your-target)')快速定位最近层叠上下文祖先
层叠关系从来不是写得越多越可控，而是删掉那些你以为“无害”的 opacity: 0.99 和 transform: translateZ(0)，才真正腾出空间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
