z-index无效主因是父容器创建了层叠上下文，使子元素z-index仅在局部生效；需检查祖先节点是否触发层叠上下文（如opacity<1、transform非none等），确保关键元素处于同一层叠上下文或提升至body级。
z-index 无效通常是因为创建了新的层叠上下文
直接设 z-index 却没效果，大概率不是写错了值，而是父容器触发了层叠上下文（stacking context），把子元素“锁死”在局部层级里。此时子元素的 z-index 只在该上下文中起作用，无法越过父级去和外部元素竞争层级。
常见触发层叠上下文的属性包括：position 非 static + z-index 不为 auto、opacity 小于 1、transform 非 none、filter 非 none、will-change 指定相关属性等。
- 检查目标元素的**所有祖先节点**是否设置了上述任一属性
- 用浏览器开发者工具的「Computed」面板查看「Stacking Context」提示（Chrome/Edge 显示为 “This element establishes a stacking context”）
- 临时移除可疑样式（如
opacity: 0.99或transform: translateZ(0)）验证是否恢复生效
父容器 z-index 值太低导致子元素再高也出不去
即使子元素设置了 z-index: 9999，如果它的直接父容器 z-index: 1，而旁边一个兄弟容器是 z-index: 100，那整个子树都会被压在下面——因为层叠比较发生在同一层叠上下文的同级元素之间。
解决的关键是：**控制层级的“入口点”必须在共同父级下对齐**。
立即学习“前端免费学习笔记（深入）”；
- 确保需要参与全局层级竞争的元素，其最近的共同祖先**不提前创建层叠上下文**
- 若必须用
transform或opacity，考虑将其上移到更高层级的容器，而非包裹目标元素的直接父级 - 避免在布局容器上滥用
z-index；真正需要分层的，应让它们处于 DOM 同一层级（比如都挂载在<body>下）
定位元素未设置 position 导致 z-index 被忽略
z-index 只对定位元素（position 为 relative、absolute、fixed 或 sticky）生效。静态定位（position: static，默认值）下设 z-index 完全无效，且不会触发层叠上下文。
从 CSV 数据集生成图数据库加载器和三元组映射。将表格 CSV 数据转换为图数据库可直接使用的节点、边和三元组。
常见误操作：
- 只写了
z-index: 10，忘了加position: relative - 用 Flex/Grid 布局时误以为子项自动获得定位能力
- CSS 重置中全局设了
* { position: static !important }，覆盖了显式声明
快速验证：在开发者工具中手动勾选元素的 position: relative，看是否立刻生效。
HTML 结构嵌套过深引发的隐式层叠隔离
当多个带 transform 的容器层层嵌套（比如轮播图内部又套弹窗再套 tooltip），每一层都可能新建层叠上下文，最终导致最内层元素的 z-index 实际作用域极小。
典型结构问题：
<div class="carousel" style="transform: translateX(0)">
<div class="slide" style="z-index: 1">
<div class="tooltip" style="position: absolute; z-index: 9999">…</div>
</div>
</div>这里 .tooltip 的 z-index 最高只能盖过 .slide 内部其他元素，但无法高于 .carousel 外的导航栏或遮罩层。
- 把需要“浮出”的元素（如 tooltip、modal、dropdown）用
Portal渲染到<body>下（React/Vue 均支持） - 纯 HTML/CSS 场景下，将这类元素提升到 body 级别，并用
position: fixed+z-index统一管理 - 避免在滚动容器（
overflow: auto）内嵌套position: fixed元素，它会相对于该容器定位而非视口
层叠上下文不是 bug，是 CSS 规范的明确行为。真正难的不是加 z-index，而是看清当前元素处在哪一层“房间”里，以及这个“房间”的门朝哪开。
