8小时摸鱼，z-index失效，有何高招？

在我的前端技术生涯中， 我曾花费了整整8个小时甚至还有更多时间在调试代码上，却主要原因是一个看似微不足道的z-index失效而感到无比沮丧。这其中充满了各种奇葩的场景、令人抓狂的报错以及我内心深处的“活到老，写到老”的感慨。

一、 Z-Index原理：数值越大越在上层

这事儿我可太有发言权了。 按照我理解的前端z-index原理，数值越大，元素在层叠上下文中的显示顺序就越靠前，从而能够避免被其他元素遮挡。简单就像一个三维空间中的物体排列方式一样。

第二、 排查步骤：F12大法

遇到z-index问题时最先做的肯定是打开开发者工具，仔细查看元素的层叠顺序和z-index值。很多文章都提到“按照前端z-index原理， 数值越大越在上层”，所以直接排查这个方向是首要任务，靠谱。。

第三、 实际案例：Popup被PageTagDiv遮挡

具体到我遇到的问题，我发现了一个令人哭笑不得的场景：一个popup组件的z-index设置为1030却依然被一个层级更高的PageTagDiv组件遮挡。 我天... 这让我一度怀疑自己是不是出现了什么严重的错误。

第四、 层叠上下文与Stacking Context

经过一番苦苦的探索后我终于明白了问题的关键所在——层叠上下文！ 很多人可能不太熟悉这个概念。它指的是HTML元素在页面上显示的层次结构。 探探路。 每个元素都属于一个或多个层叠上下文。当多个元素存在于同一个层叠上下文中时它们会按照一定的规则进行重叠排序。

重点提示：记住啊！我们说的“层叠水平”和“层叠顺序”都是概念性的描述。真正的影响因素是元素的定位属性和父元素的定位属性。

二、解决问题：调整容器位置

原来啊！问题不在于z-index`本身的问题，而在于这两个组件并没有位于同一个HTML根元素中！ PPT你。 它们分别位于不同的DOM树中。这意味着它们所处的层叠上下文不同。

为了解决这个问题，我尝试将弹出窗口的容器设置为返回到`body`元素。 通过设置父元素的position属性为relative、absolute或fixed也能创建新的层叠上下文，精神内耗。。

三、ZIndex 的其他注意事项

为什么inline/inline-block元素的层叠顺序比浮动元素和块元素都高呢？

原因很简单：inline 和 inline-block 元素通常用于内容展示而非布局。 我心态崩了。 它们会优先显示于屏幕上。

四、与思考

关于z-index的问题还真是千奇百怪！ 除了确保元素的定位属性正确外 还需要注意以下几点：，小丑竟是我自己。

• 父元素的定位
• 同一层的叠加规则
• 浏览器差异

五、补充说明

MDN官方解释

六、近期项目中遇到的类似问题

七、关于Layering Context 的更深一层理解