前言
在现代复杂布局中，z-index是无法绕过的，如果不仔细规划，后期就会越来越无法维护。小型项目中可能问题不大，大型项目就会郁闷了。
常识
https://www.cnblogs.com/starof/p/4424926.html 这篇文章写的很好，现在假设我们都已经仔细读过了文章。
其中最核心的概念有2个：
可定位元素：
支持top/bottom/left/right的元素，也就是说，除了static元素，剩下的都是可定位元素。z-index只在可定位元素上生效。
堆叠上下文：
stacking context翻译就是“堆叠上下文”，也叫堆叠语境。每个元素仅属于一个堆叠上下文，元素的z-index描述元素在相同堆叠上下文中“z轴”的呈现顺序。
堆叠上下文就是各代祖先中最近它的那个非static元素。
如何轻易的判断两个元素的堆叠顺序？
从上面引用的cnblog的文章可以知道，z-index对堆叠顺序的控制类似于排版时候一大章下几个小节的样子，或者版本号中一个大的版本号跟着小版本号，比如4.2.4，注意，不要把版本号理解为数学中的小数。
Root - z-index值为默认auto，即0
- DIV #2 - z-index 值为2
- DIV #3 - z-index 值为4
- DIV #5 - z-index值为 1,其父元素z-index值 4,所以计算值为4.1
- DIV #7 - z-index值为 5,其父元素z-index值 1,其祖父元素z-index值 4,所以计算值为4.1.5
- DIV #6 - z-index值为 3,其父元素z-index值 4,所以计算值为4.3
- DIV #4 - z-index值为 6,其父元素z-index值 4,所以计算值为4.6
- DIV #5 - z-index值为 1,其父元素z-index值 4,所以计算值为4.1
- DIV #1 - z-index 值为5
找不到堆叠语境怎么办？
如果一个可定位元素，一直找到<html>元素都找不到堆叠上下文，那么它的堆叠语境就是root，它的z-index“计算值”就是它的z-index值本身。
fixed元素的堆叠上下文是啥？
上面引用的文章已经说了，凡是非static元素，都是有堆叠上下文的，fixed元素也不例外。但是它又有点特殊，因为它不是以某个元素为定位祖先（定位祖先就是可定位的元素的定位参照对象，也就是到底相对于谁来定位），而是始终以浏览器视口为定位参照，那么，fixed的堆叠上下文又是哪个元素呢？是<html>元素么？并不是。
简单说，我们先将fixed元素视为absolute元素，然后再考虑它的z-index就行了，它的堆叠上下文就是各代祖先中离它最近的那个非static元素。
z-index赋值个人最佳实践
z-index应当怎么安排值，没有一个行业标准，都是自己定，我个人认为的标准如下：
第一步
将一个页面分为四级，排列如下（写在上的表示页面内在上）：
- 弹出层（modal）
- 蒙版层（mask）
- 导航层（nav）
- 内容层（content）
然后给这四层分别设一个基础z-index值，比如：
- 弹出层：30
- 蒙版层：20
- 导航层：10
- 内容层：static元素
在DOM中体现出这四个层，比如：
<body>
<div class="content-layer">
</div>
<div class="nav-layer">
</div>
<div class="mask-layer">
</div>
<div class="popout-layer">
</div>
</body>
将content层细分
什么意思？想象一个复杂的手机APP，或者你可以现在安装一个“美团外卖”APP，我们现在把它当做一个webapp，然后分析它。
毫无疑问，它有content层，也有导航层，蒙版层，弹出层，但是，它的content层又有细分，比如局部的蒙版层，局部的导航层，局部的弹出层，也就是说，比如蒙版层，这个蒙版层并没有压住全部手机屏，而是只压住了局部，比如弹出层，有些弹出层是基于content层的一部分面积居中弹出，所以它不是全局弹出层。
因此，我的做法是，给全局content层细分，形成若干个局部content，然后，每个局部content可以继续拆分为某些部分，各个部分又可以有自己的content层、导航层、蒙版层、弹出层。
那么z-index又怎么规定呢？
并不需要规定。通常，只需要给该部分的HTML代码内部下方追加类似于下面的代码即可：
<div class="section">
...content层内容...
<div class="mask"></div>
<div class="popout">...</div>
</div>
这两个新增的div设上类似于下面的css：
.section .mask {
position: absolute;
top: 0;
right: 0;
left: 0;
bottom: 0;
background: rgba(0,0,0,.5);
}
.section .popout {
position: absolute;
top: 0;
right: 0;
left: 0;
bottom: 0;
background: #fff;
}
可以看到，并不需要设z-index，层次并不会出现异常。
为什么一些著名网站的z-index都在几千的数量级上？而本文都是几十数量级？
首先说，几千数量级的z-index是否有必要？
我认为，至少对于一个小型项目来讲，没有必要。因为：
就像我上面说的最佳实践，几十数量级足够用。为什么？
尽管上文强调过，这里还是要强调，z-index是有语境的，除了拿章节做类比，还可以拿军队做类比，比如某国陆军，有一个班，它的编号是：“第一军第一师第一团第一营第一连第一排第一班”，看到了么？虽然编号的数量级很小，却能精确定位一个班，如果某国陆军有9个军，那么，用个位数的编号就能定位9 * 9 * 9 * 9 * 9 * 9 * 9 = 4782969个班，所以，z-index几十的数量级足够。
然后说，为什么大型项目却设了几千的数量级？
因为：
- 豪放。是的，几十数量级的z-index显得很小家子气。这其实是最大的理由。
- 根据我上文的最佳实践，假设，A父元素中有一个a子元素，B父元素有一个b子元素，A和B是兄弟元素，a和b相交，我认为的最佳实践是A的z-index设为10，B设为11，子元素都不设任何z-index。但是国外大型项目并不是这个实践，他们会忽略堆叠上下文，试图给所有可定位元素统一排序，比如A的z-index可能已经是1100，a就是1110，B是1200，b是1210。这样做的好处就是，阅读代码的人能一目了然，坏处就是编写代码的人累。
- 给后续开发和改版留余地。比如，从前级联菜单是省市县乡，现在是国家省市县乡，最前面增加了一层国家列表，那么它的z-index就要比之前写的省市县乡要小，如果不给国家列表留余地，就需要改动省市县乡的z-index。当然了，改改省市县乡的z-index也并不是多大的工作量，但是如果这个系统有20个位置都有这种省市县乡列表呢？那改起来就有点想吐了。
所以，究竟用哪种方式，就看你个人想法了。
